Hi Tony,
                  Thanks for the info. I got it now. That means I need to create a separate COW file for each instance which will have the image of same root_fs.
Thanks again,

On 5/30/06, Brock, Anthony - NET <Anthony.Brock@oregonstate.edu> wrote:
You need to create a separate COW file (probably based of the same original image) for each instance. Your customizations will then be written to the COW file while preserving the base image intact. This will also bypass the file locking issue.

From: Pranjal Kumar Dutta [mailto:pranjalkumardutta@gmail.com]
Sent: Tuesday, May 30, 2006 10:57 AM
To: Brock, Anthony - NET
Cc: user-mode-linux-user@lists.sourceforge.net
Subject: Re: [uml-user] Problems in sharing filesystems between Virtual Machines

But I am facing another problem. I have created the COW file and UML boots properly. But now when I boot another UML instance from the COW file I get the followimg error: It shows file is already locked by pid ... 

#include <s@Kanaloa um32-2.6.15-release-mod]$ ls -al

total 622708

drwxr-xr-x 2 root root 4096 May 30 23:07 .

drwxr-xr-x 18 root root 4096 May 30 22:08 ..

-r--r--r-- 1 root root 618659840 May 30 02:41 root_fs                <------------this is the root filesystem

-rwxr-xr-x 1 root root 618819584 May 30 23:16 root_fs.cow     <-------------thie is the COW file

-rwxr-xr-x 1 root root 3171720 Jan 17 20:06 vmlinux-2.6.15-bs1

[pdutta@Kanaloa um32-2.6.15-release-mod]$ ./vmlinux-2.6.15-bs1 ubd0=root_fs.cow

devfs=nomount rw

Checking that ptrace can change system call numbers...OK

Checking syscall emulation patch for ptrace...OK

Checking advanced syscall emulation patch for ptrace...OK

Checking PROT_EXEC mmap in /tmp...OK

Checking for the skas3 patch in the host:

- /proc/mm...found


- PTRACE_LDT...found

UML running in SKAS3 mode

Linux version 2.6.15-bs1 (paolo@zion) (gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)) #1 Tue Jan 17 15:36:29 CET 2006

Built 1 zonelists

Kernel command line: ubd0=root_fs.cow devfs=nomount rw root=98:0

PID hash table entries: 256 (order: 8, 4096 bytes)

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 28988k available

Mount-cache hash table entries: 512

Checking for host processor cmov support...Yes

Checking for host processor xmm support...No

Checking that host ptys support output SIGIO...Yes

Checking that host ptys support SIGIO on close...No, enabling workaround

Checking for /dev/anon on the host...Not available (open failed with errno 2)

Using 2.6 host AIO

NET: Registered protocol family 16

mconsole (version 2) initialized on /home/pdutta/.uml/dHsexi/mconsole

ubd: Synchronous mode

VFS: Disk quotas dquot_6.5.1

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

Initializing Cryptographic API

io scheduler noop registered

io scheduler anticipatory registered

io scheduler deadline registered

io scheduler cfq registered

loop: loaded (max 8 devices)

NET: Registered protocol family 2

IP route cache hash table entries: 512 (order: -1, 2048 bytes)

TCP established hash table entries: 2048 (order: 1, 8192 bytes)

TCP bind hash table entries: 2048 (order: 1, 8192 bytes)

TCP: Hash tables configured (established 2048 bind 2048)

TCP reno registered

TCP bic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

Initialized stdio console driver

Console initialized on /dev/tty0

Initializing software serial port version 1

F_SETLK failed, file already locked by pid 2720

Failed to lock 'root_fs.cow', err = 11

Failed to open 'root_fs.cow', errno = 11

VFS: Cannot open root device "98:0" or unknown-block(98,0)

Please append a correct "root=" boot option

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0)

EIP: 0073:[<a0163f01>] CPU: 0 Not tainted ESP: 007b:b7f25fb8 EFLAGS: 00000246

Not tainted

EAX: 00000000 EBX: 00000b49 ECX: 00000013 EDX: 00000b49

ESI: 00000b45 EDI: 00000000 EBP: b7f25fc4 DS: 007b ES: 007b

a08a7b34: [<a00253df>] show_regs+0x187/0x18f

a08a7b5c: [<a0011084>] panic_exit+0x25/0x3f

a08a7b6c: [<a00375eb>] notifier_call_chain+0x1c/0x3a

a08a7b8c: [<a0028e0e>] panic+0x4b/0xc3

a08a7ba4: [<a000187a>] mount_block_root+0xbb/0xcf

a08a7bf8: [<a00018df>] mount_root+0x51/0x56

a08a7c0c: [<a0001975>] prepare_namespace+0x91/0xbd

a08a7c1c: [<a000b1ed>] init+0x73/0x12a

a08a7c30: [<a00201b4>] run_kernel_thread+0x28/0x2c

a08a7cdc: [<a0014a92>] new_thread_handler+0xc6/0xf8

a08a7d1c: [<ffffe420>] _etext+0x5fe4da6a/0x0

[pdutta@Kanaloa um32-2.6.15-release-mod]$ vi errlog.txt


[pdutta@Kanaloa um32-2.6.15-release-mod]$ vi errlog.txt

[pdutta@Kanaloa um32-2.6.15-release-mod]$ su


[pdutta@Kanaloa um32-2.6.15-release-mod]#



On 5/30/06, Pranjal Kumar Dutta <pranjalkumardutta@gmail.com > wrote:
           I am now able to create  a COW filesystem through uml_mkcow utility and then booting the UML with ubd0=root_fs.cow successfully.

On 5/30/06, Brock, Anthony - NET <Anthony.Brock@oregonstate.edu > wrote:
Do you have write permissions to the current working directory? I don't know what err=113 means, but the guest instance needs permissions to create the file on the local file system.

From: user-mode-linux-user-admin@lists.sourceforge.net [mailto:user-mode-linux-user-admin@lists.sourceforge.net] On Behalf Of Pranjal Kumar Dutta
Sent: Monday, May 29, 2006 11:54 PM
To: user-mode-linux-user@lists.sourceforge.net
Subject: [uml-user] Problems in sharing filesystems between Virtual Machines

          I am facing a problem in sharing a single root fileystem between multiple UML instances through COW (Copy on write). I am following the steps given in
http://user-mode-linux.sourceforge.net/shared_fs.html  for sharing fileystems between multiple UML instances.
I am using the root_fs.rh-9-full.pristine.20030724.bz2     root filesystem from  http://www.stearns.org/uml-root/ .
When I start my UML instance with ./vmlinux ubd0=root_fs_cow, root_fs_sh9_pristine  devfs=nomount rw, it failes to boot up saying that can't open root_fs_cow err=113 etc. As per the steps given in the link it's not necessary to have a root_fs_cow and willl create when UML booted up fisrt time, right?