[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] libvirt, libxl and QDISKs



Hi,

Now that libxl + qemu's built-in disk backend for ceph/rbd is working nicely, I'm trying to get it all working through libvirt.

When libvirt's libxl driver creates a libxl_device_disk, it applies a few simple rules[1] covering specific file format types (qcow, qcow2, vhd). If none of these rules apply then it defers to libxl's best guess:

            * If driverName is not specified, default to raw as per
            * xl-disk-configuration.txt in the xen documentation and let
            * libxl pick a suitable backend.
            */
            x_disk->format = LIBXL_DISK_FORMAT_RAW;
            x_disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;

The libxl code in libxl__device_disk_set_backend[2] tries to resolve 'UNKNOWN' into something concrete by calling 'disk_try_backend':

            disk_try_backend(&a, LIBXL_DISK_BACKEND_PHY) ?:
            disk_try_backend(&a, LIBXL_DISK_BACKEND_TAP) ?:
            disk_try_backend(&a, LIBXL_DISK_BACKEND_QDISK);

Unfortunately for me and my quest, the case for LIBXL_DISK_BACKEND_TAP just checks for
 * lack of hotplug script
 * libxl__blktap_enabled
 * DISK_FORMAT_{RAW,VHD}
and so it selects TAP and then fails, because tapdisk doesn't know anything about this disk access protocol (yet at least). Unbeknownst to libxl, qemu would be able to handle the disk in this case.

I'm not sure what the best way to address this is. I could disable blktap on my system but it would be a shame to drop support for the stuff tapdisk does well (like .vhd handling)

On the other hand, having both tapdisk and qemu means having to choose
between them for disk protocols they could both handle. A choice would
either have to be coded in libxl (or libvirt's libxl driver), which seems like a bit of an annoying maintenance burden (i.e. update the list every time someone adds a driver somewhere); or it could be left to the sysadmin to choose via some kind of resolver script, which seems a bit complex.

A third possibility is to be able to ask tapdisk, "do you actually support this disk" and if yes, use it in preference to qemu, if no fall back to qemu.

Anyone got any thoughts? (Or perhaps I've missed something obvious! :-)

Cheers,
Dave

[1] http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libxl/libxl_conf.c;h=7e0753a69ed4a0867d14843cbad20d1430a67f0c;hb=HEAD#l462

[2] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_device.c;h=eeea9d9a023877a69ff2832c973e753629333356;hb=HEAD#l219

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.