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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Apr 25, 2013 at 9:55 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2013-04-24 at 15:22 +0100, 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.
>
> Can you specify driverName in your config somehow? I confess I don't
> know if this is ~= format or backend...
>
>> Anyone got any thoughts? (Or perhaps I've missed something obvious! :-)
>
> This is not the first time that the issue of hardcoded defaults in libxl
> has come up recently (in fact I think you mentioned one of the others to
> me...).
>
> It seems to me that there is a need arising for a system wide libxl
> configuration file which sets these sorts of defaults for all users of
> libxl on that system and which can be modified according to admin
> preference. As well as the disk backend selection (which is actually
> probably pretty complex to express in a simple configuration file) this
> has come up in the context of stubdomain usage and autoballooning.

Something like this was actually on my "to-implement" feature list for
4.3, but no one got around to it, so I dropped it.

FWIW, I think having this kind of thing would make 4.3 betterer enough
that it would be worth slipping the release for a few weeks to get it
in.

On the other hand, experience has shown that converging on what the
"right" interface should be take a heck of a lot longer than you
think; so maybe we should just plan on doing this for 4.4 at this
point.

 -George

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