[Xen-users] Xen-3.4.3 PV and BlkTap2?

[Philipp Hahn <hahn@xxxxxxxxxxxxx>]

Hello,

does Xen-3.4.3 work for a para-virtualized domain using blktap2?

For me it doesn't, but I don't know if my setup is faulty or this setup isn't 
supported:
> bootloader = '/usr/bin/pygrub'
> bootargs = '-q --args="console=hvc0 nosplash verbose"'
> memory = 512
> name = "tap"
> vif = [ 'type=ioemu,bridge=eth0' ]
> disk = [
> 'tap:aio:/var/lib/images/ucs_2.4-0-20100729110150-dvd-amd64.iso,xvdb:cdrom,
>r', 'tap:aio:/var/lib/images/ucs24rc_64.img,xvda,w',
> ]

PyGrub is able to extract the Kernel and InitRamFs fine, but than init waits 
for the block devices to appear, which never happens:
> XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...

Running "udevadm monitor --env" I see the two UDEV and UEVENT events for both 
devices, "/etc/xen/scripts/blktap add" get calles, but nothing happens:
> UEVENT[1281536697.710947] add      /devices/tap-8-51728 (xen-backend)
> ACTION=add
> DEVPATH=/devices/tap-8-51728
> SUBSYSTEM=xen-backend
> XENBUS_TYPE=tap
> XENBUS_PATH=backend/tap/8/51728
> XENBUS_BASE_PATH=backend
> SEQNUM=3055
>
> UDEV  [1281536697.713278] add      /devices/tap-8-51728 (xen-backend)
> UDEV_LOG=3
> ACTION=add
> DEVPATH=/devices/tap-8-51728
> SUBSYSTEM=xen-backend
> XENBUS_TYPE=tap
> XENBUS_PATH=backend/tap/8/51728
> XENBUS_BASE_PATH=backend
> SEQNUM=3055
> UDEVD_EVENT=1
>
> UEVENT[1281536697.731574] add      /devices/tap-8-51712 (xen-backend)
> ACTION=add
> DEVPATH=/devices/tap-8-51712
> SUBSYSTEM=xen-backend
> XENBUS_TYPE=tap
> XENBUS_PATH=backend/tap/8/51712
> XENBUS_BASE_PATH=backend
> SEQNUM=3056
>
> UDEV  [1281536697.738740] add      /devices/tap-8-51712 (xen-backend)
> UDEV_LOG=3
> ACTION=add
> DEVPATH=/devices/tap-8-51712
> SUBSYSTEM=xen-backend
> XENBUS_TYPE=tap
> XENBUS_PATH=backend/tap/8/51712
> XENBUS_BASE_PATH=backend
> SEQNUM=3056
> UDEVD_EVENT=1

If I change the domain description to full virtualization (HVM), tap:aio seems 
to work:
> - bootloader = '/usr/bin/pygrub'
> - bootargs = '-q --args="console=hvc0 nosplash verbose"'
> + kernel = "/usr/lib/xen/boot/hvmloader"
> + builder='hvm'
> + device_model = '/usr/lib/xen/bin/qemu-dm'

After that a "qemu-dm" is running which has the image files opened for IO.

What I currently don't understand is which process is supposed to handle the 
blktap2-requests in para-virtualized domains? To me it looks like there's 
something missing in xen-3.4.3, which is only part of xen-4.x.

Perhaps somebody can shed some light on how this is supposed to work. My 
current understanding of the situation is as following:
- for older non-PvOpts-Xen-versions blktap1 was used. When the domains was 
startet, Xend wrote some "magic setting" in XenStore, which triggered the 
forking of a sub process to handle the aio requests.
- newer PvOpts-Xen-versions (3.4.3, 4.x) depends on PvOpts-capable Linux 
kernels (>=2.6.32), which don't support blktap1 anymore, but only blktap2.
- for blktap2 the handling is different: some process (?) must be started to 
handle the aio-requests. This is no longer done by Xend/Xenstored, but by 
some other thing (?).

I hope somebody can enlighten me. Thank your for your time.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn@xxxxxxxxxxxxx   
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users