libvirt, libxl and QDISKs

[David Scott <dave.scott@eu.citrix.com>]

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