[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


  • To: George Shuklin <george.shuklin@xxxxxxxxx>, "xen-api@xxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxx>
  • From: Joseph Hom <jhom@xxxxxxxxxxxxx>
  • Date: Tue, 8 Jan 2013 18:29:37 +0000
  • Accept-language: en-US
  • Delivery-date: Tue, 08 Jan 2013 18:29:54 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>
  • Thread-index: AQHN6t/ZCqYUoQd0n0ym4a/KjLYtEJg6lfoAgAAm0QCABWgiAP//oGlg
  • Thread-topic: [Xen-API] look into VHD VDI from Control Domain in XCP 1.6

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®.