xen discuss - Aug 2006 - How to correctly attach and detach a disk image to a running Solaris DomU?

Hi,

next question:

How to correctly attach and detach a disk image to a running Solaris DomU?

I can attach & and use the disk image (but I''m not sure if I use
the
correct syntax) but I can not detach the image form the running Solaris 
DomU.


For Linux DomUs the following works:

bash-3.00# xm block-attach xen-debian 
file:/export/xen-images/datadisk.img sda2 w

# mount, use, and remount  the disk image in the Linux DomU

bash-3.00# xm block-detach xen-debian sda2


For Solaris DomUs I get:

# ### inside the Dom0
#

# list the running Domains
#
bash-3.00# xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      512     1 r-----   318.2
mydomU1                           11      400     1 ------    11.4

#  list the block devices attached to the DomU
#
bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/11/0


# attach the new disk image
#
bash-3.00# xm block-attach mydomU1 
file:/export/xen-images/soldatadisk.img sda1 w

# list the attach disk images
#
bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/12/0
2049    0    0     1      -1     -1    /local/domain/0/backend/vbd/12/2049


# ### inside the Solaris DomU
#

# list the disk devices before attaching the new disk image
#
bash-3.00# ls /dev/dsk
c0d0s0  c0d0s1  c0d0s2  c0d0s3  c0d0s4  c0d0s5  c0d0s6  c0d0s7

# run defvfsadm *after* attaching the new disk image
#
bash-3.00# devfsadm

# list the disk devices after attching the new disk image
#
bash-3.00# ls /dev/dsk
c0d0s0          c0d0s4          c0d134511440s0  c0d134511440s4
c0d0s1          c0d0s5          c0d134511440s1  c0d134511440s5
c0d0s2          c0d0s6          c0d134511440s2  c0d134511440s6
c0d0s3          c0d0s7          c0d134511440s3  c0d134511440s7

# create a new filesystem on the new attached disk image
#
bash-3.00# newfs /dev/rdsk/c0d134511440s0
newfs: construct a new file system /dev/rdsk/c0d134511440s0: (y/n)? y
/dev/rdsk/c0d134511440s0:       102340 sectors in 170 cylinders of 1 
tracks, 602 sectors
        50.0MB in 11 cyl groups (16 c/g, 4.70MB/g, 2240 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 9664, 19296, 28928, 38560, 48192, 57824, 67456, 77088, 86720,
 96352

# mount the new attached disk image
#
bash-3.00# mount /dev/dsk/c0d134511440s0 /mnt
bash-3.00# ls /mnt
lost+found

bash-3.00# cp /usr/bin/bash /mnt
bash-3.00# umount /mnt

# umount the new attached disk image
#
bash-3.00# umount /mnt


# ### in the Dom0 again
#
# NOTE : The detach seems not to work (or I do not know the correct Syntax)
#
# detach the new disk image from the DomU
#
bash-3.00# xm block-detach mydomU1 sda1

bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/12/0
2049    0    0     7      7      639   /local/domain/0/backend/vbd/12/2049

bash-3.00# xm block-detach mydomU1 2049

bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/12/0
2049    0    0     7      7      639   /local/domain/0/backend/vbd/12/2049


-- 
Bernd Schemmer, Frankfurt am Main, Germany
http://home.arcor.de/bnsmb/index.html

Más temprano que tarde el mundio cambiará
                        Fidel Castro

Hi,

did some more tests and found a working solution (see below) But I still
don''t know if this is a correct usage.

BTW:

After doing a 

xm block-attach mydomU1 file://export/xen-images/soldatadisk.img c3 rw

I can only mount the disk read-only inside in the DomU. If I want to mount it
read/write I must use

xm block-attach mydomU1 file://export/xen-images/soldatadisk.img c3 w

Is this working as designed?

regards

Bernd




# ### in the Dom0

bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/10/0

bash-3.00# xm block-attach mydomU1 file://export/xen-images/soldatadisk.img c3 w

bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/10/0
195    0    0     1      -1     -1    /local/domain/0/backend/vbd/10/195


# ### in the DomU
#
bash-3.00# ls /dev/dsk
c0d0s0  c0d0s1  c0d0s2  c0d0s3  c0d0s4  c0d0s5  c0d0s6  c0d0s7

bash-3.00# devfsadm

bash-3.00# ls /dev/dsk
c0d0s0    c0d0s2    c0d0s4    c0d0s6    c0d195s0  c0d195s2  c0d195s4  c0d195s6
c0d0s1    c0d0s3    c0d0s5    c0d0s7    c0d195s1  c0d195s3  c0d195s5  c0d195s7


bash-3.00# mount -o rw /dev/dsk/c0d195s0 /mnt

bash-3.00# ls /mnt
bash        lost+found

bash-3.00# cp /usr/bin/basename /mnt

bash-3.00# ls /mnt
basename    bash        lost+found

bash-3.00# df -k /mnt
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0d195s0      47897    1681   41427     4%    /mnt


bash-3.00# umount /mnt


# ### in the Dom0
#

bash-3.00# xm block-detach mydomU1 c3

bash-3.00# xm block-list mydomU1
Vdev  BE handle state evt-ch ring-ref BE-path
0      0    0     4      5      8     /local/domain/0/backend/vbd/10/0



# ### in DomU
#
bash-3.00# ls /dev/dsk
c0d0s0    c0d0s2    c0d0s4    c0d0s6    c0d195s0  c0d195s2  c0d195s4  c0d195s6
c0d0s1    c0d0s3    c0d0s5    c0d0s7    c0d195s1  c0d195s3  c0d195s5  c0d195s7

bash-3.00# devfsadm -C

bash-3.00# ls /dev/dsk
c0d0s0  c0d0s1  c0d0s2  c0d0s3  c0d0s4  c0d0s5  c0d0s6  c0d0s7
 
 
This message posted from opensolaris.org

Hi Bernd,

Bernd Schemmer wrote:
> Hi,
> 
> did some more tests and found a working solution 
 > (see below) But I still don''t know if this is a correct
usage.
> 
> BTW:
> 
> After doing a 
> 
> xm block-attach mydomU1 file://export/xen-images/soldatadisk.img c3 rw
> 
> I can only mount the disk read-only inside in the DomU. If I want to mount
it read/write I must use
> 
> xm block-attach mydomU1 file://export/xen-images/soldatadisk.img c3 w
> 
> Is this working as designed?
I wouldn''t think so.   :-)

Max is looking at it right now.. He''s working on some other
improvements/bug fixes to the disk back end attach/detach
path now so hopefully he can included this with it..

Thanks for all your help!



Thanks,


MRJ

It appears my response to the first question (r, rw, w) created a new thread vs.
responding to this.

Read-only disks are specified with ''r'', read/write as
''w''.  If you specify ''rw'', xend only looks
at
the first character and treats it as read-only.

Regarding the next question about detaching block devices.  If the domU has not
attached
the device, xm block-detach should remove the device successfully from the domU.
There
is a bug where the domU does not yet handle change events for front-end devices.
We are
working on fixing this - which will also remove the need to run devfsadm
manually on the
domU after xm block-attach.

-john
 
 
This message posted from opensolaris.org

John,

thanks for the info.
>> It appears my response to the first question (r, rw, w) created a new
thread vs. >>responding to this.
Yep, and in general the other discussions are better sorted than the Xen
discussion . I can''t image why because I think the software used for
all discussions is the same.

And the Xen discussion is the only one with a lot of spam...

Anyway - Xen for Solaris  is worth ignoring all these issues ....

Thanks for the great work

Bernd
 
 
This message posted from opensolaris.org

On 8 Aug 2006, at 7:48pm, Bernd Schemmer wrote:
> And the Xen discussion is the only one with a lot of spam...
''Member only posting'' was enabled a week or so ago, so the
spam
should not continue.

dme.
-- 
David Edmondson, Solaris Engineering, http://www.dme.org