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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-04-25 at 11:36 +0100, George Dunlap wrote:
> 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.

I don't think this can/should be rushed at this point.

Ian.


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