Re: [Xen-devel] libvirt, libxl and QDISKs

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 24 Apr 2013, David Scott wrote:
> 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! :-)

I vote for using blktap exclusively for VHD files.
In fact we do know that blktap support is not great for anything else
anyway (qcow2 I am thinking about you).

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