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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home