[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] look into VHD VDI from Control Domain in XCP 1.6



Yep, but what the uuid is that '55ea...'? I xee it nowhere in related objects:

uuid ( RO)             : 9a4ee27b-d990-4887-ff49-e2c1fb100061
          vm-uuid ( RO): 53c3d878-b60b-48ec-aaac-73f7adf9ab3d
    vm-name-label ( RO): Control domain on host: test
         vdi-uuid ( RO): 5e2c31a5-1d1b-4abe-9892-1fa3bc47b532
            empty ( RO): false
device ( RO): sm/backend/55ea20d2-8611-1121-9e9e-c26b35ac1852/5e2c31a5-1d1b-4abe-9892-1fa3bc47b532

.....

After some guessing: this is SR uuid.

xe vdi-list uuid=5e2c31a5-1d1b-4abe-9892-1fa3bc47b532
uuid ( RO)                : 5e2c31a5-1d1b-4abe-9892-1fa3bc47b532
          name-label ( RW): test1
    name-description ( RW):
             sr-uuid ( RO): 55ea20d2-8611-1121-9e9e-c26b35ac1852
        virtual-size ( RO): 2147483648
            sharable ( RO): false
           read-only ( RO): false



08.01.2013 22:29, Joseph Hom ÐÐÑÐÑ:
That is due to the new sm backend that was introduced. When a vbd is plugged 
into dom0 is no longer shows up as a straight block device under /dev/

The new version of xe-edit-bootloader addresses this and can be used as a 
pointer on what to do.

Hint: kpartx -av /dev/sm/backend/55ea20d2-8611-1121-9e9e-c26b35ac1852
ls /dev/mapper/55ea20d2-8611-1121-9e9e-c26b35ac1852*

-----Original Message-----
From: xen-api-bounces@xxxxxxxxxxxxx [mailto:xen-api-bounces@xxxxxxxxxxxxx] On 
Behalf Of George Shuklin
Sent: Tuesday, January 08, 2013 12:08 PM
To: xen-api@xxxxxxxxxxxxx
Subject: Re: [Xen-API] look into VHD VDI from Control Domain in XCP 1.6

Ok, here important stuff. When VBD is plugged to dom0, it plugging not as 
'normal' device (with udev attention), but as device in /dev/sm/backend.

Here sample log (change uuids on you taste):

xe vbd-create vm-uuid=53c3d878-b60b-48ec-aaac-73f7adf9ab3d
vdi-uuid=5e2c31a5-1d1b-4abe-9892-1fa3bc47b532 device=6 xe vbd-plug 
uuid=407eb3a6-919f-f605-0883-e12aaa91321d

ls -la /dev/sm/backend/55ea20d2-8611-1121-9e9e-c26b35ac1852/
ÐÑÐÐÐ 4
drwxr-xr-x 2 root root     80 ÐÐÐ  8 21:57 .
drwxr-xr-x 3 root root     60 ÐÐÐ 18 17:40 ..
brw------- 1 root root 253, 0 ÐÐÐ  8 21:57
5e2c31a5-1d1b-4abe-9892-1fa3bc47b532
-rw-r--r-- 1 root root    852 ÐÐÐ  8 21:57
5e2c31a5-1d1b-4abe-9892-1fa3bc47b532.attach_info

I have no idea why '55' uuid (and what it means), but
5e2c31a5-1d1b-4abe-9892-1fa3bc47b532 is block device after whole VHD tree 
joining/parsing and so on.

You can see actual path in xe vbd-list output (device field).

05.01.2013 11:33, Alexandre Kouznetsov ÐÐÑÐÑ:
Hello.

El 04/01/13 23:14, George Shuklin escribiÃ:
Use xe vbd-create between vdi and dom0 (which is normal VM mostly),
and xe vbd-plug.
Yes, that's what I have done following the example from Citrix forum.

In case of a normal DomU:
I create VBD linking the VM with VDI,
I issue vbd-plug,
the block device becomes visible in dmesg under DomU.

In case of Dom0:
I create VBD linking the VM (vm-list refers to it as "Control Domain",
no mistake) with VDI, I issue vbd-plug, no sign of the new block
device in dmesg or under /dev.

You can see some sample usage in 'xe-edit-bootloader' command
(somewhere in /opt/xensource/)
Hm. I believe I'm doing it just the same way as in the script, except
by the "device=" directive for vbd-create, use specific string like
"xvdn".
Should it make the difference? Can't test, I shot down my testing
range before leaving the office.

So, must I understand that the XCP's regular way of manipulating VDI's
contents from within Dom0, is attaching the VDI to it via a VBD?
Looks like a good abstraction, except that it won't work that easily
on a host without XCP infrastructure (for example, in some rescue
scenario).

Then, what vhdpartx is good for?

Cheers.


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.