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@univention.de
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/
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users