[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 wouldeither 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |