[Xen-users] RFH: loopback & blktap(2) and CDROM

[Philipp Hahn <hahn@xxxxxxxxxxxxx>]

Hello,

I'm currently trying to understand some problems I had in the past with mixing 
look-back with blktap(2) for HV and PV domains. I'm stuck reading the source 
code, so I'd like to get some help from the list. Interrupt me if I got 
something fundamentally wrong in my understanding so far:

1. With pure-HV the domU gets an emulated IDE (or whatever) disk. The 
emulation is done by qemu-dm, which opens whatever is given to it: directly a 
file, a block-device in dom0, etc.

2. With pure-PV the domU does not get an emulated IDE, but must use blkfront 
to access the disk. For this to work blkback needs a block device, which is 
either directly taken from a dom0 block device or provided via look-back or 
blktap.

3. Because of PVonHVM Xen provides the domU with both an IDE view and an XVD 
view of evey block device. The domU boots using the IDE view and when the PV 
drivers are loaded, disables the emulated view and switches over to the XVD 
view.

Now some questions:

4. I read somewhere that "mixing loobback with tapdisk is a bad idea", but I 
can't find that again, so I'm wondering if that (wrong) claim got somehow 
stuck in my memory. I can only imagin two scenarios
a) one domU accessing two disk images, one with lookback, the other one with 
blktap. That looks okay.
b) two domUs accessing the same disk image, one with lookback, the other one 
with blktap. That looks broken but neither would I expect that to work 
(shared disk semantics aside)

5. While experimenting with a Linux domU I noticed that the boot process 
sometimes gets stuck when I declare one disk as "hda" and a second one 
as "xvda". The 2.6.32 kernel detects a clash in /sys/block naming and I'm 
stuck in the "XENBUS: Waiting for devices to initialise: 295s..." count down.
Is this because hda and xvda overlap because of the PVonHVM case 
(ide-block-major has 64 minors per device for partitions, while 
scsi-block-major and xen-block-major only have 16 minors per device, that is 
hda=xvd[abcd], hdb=xvd[efgh], ...)?

6. How should I make an .iso image file accassable to a domU?
If a use tap:/var/lib/libvirt/images/some.iso tapdisk2 claims the image and 
passes phy:/dev/xen/blktapX to qemu-dm, which I can access fine, but eject 
does not work, since qemu only sees the phy: device and can't open another 
file.
xen-blockfront in PVonHVM and Windows-GPLPV driver both reject CDROM-devices, 
so the CDROM remains IDE emulated. With 
GPLPV /local/domain/0/backend/vbd/18/768/state changes from "1" â "4", while 
with Linux it changes to "6" as soon as the Xen modules probe the XenBus. 
After that Xend refused to change the medium with the following error:
> error: POST operation failed: xend_post: error from xen daemon: 
(xend.err 'Device 5632 not connected')
Today I did another test, were it worked fine, so my problem might not even be 
related to the state change.
Since Xend needs to allocate a lookback device for each ISO, which is then 
never used by the PVonHVM drivers, can I tell Xend to not allocate a loopback 
device and only let qemu-dm open the file?


So this looks like I should use file:ioemu:/var/lib/libvirt/images/some.iso 
instead for HV domUs, because QEMU would be able to open the file itself (and 
change it). Any loopback or blktap would be pointless, because the PVonHVM 
drivers refuse to work for CDROMs any way.

But for PV-domUs there's no qemu-dm doing IDE emulation, so using blktap or 
loopback there is a must.

Correct?

Thanks for your time and feedback in advance.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn@xxxxxxxxxxxxx
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users