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-boun...@lists.xen.org [mailto:xen-api-boun...@lists.xen.org] On
Behalf Of George Shuklin
Sent: Tuesday, January 08, 2013 12:08 PM
To: xen-api@lists.xen.org
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@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
