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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 25 Apr 2013, Ian Campbell wrote:
> 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.

Right, but going back to the original question: if we have in our hands
something that is not vhd, raw or qcow and blktap2 is available,
should we really try to pass it to it?

We do know that blktap2 only handles qcow, qcow2, raw and vhd (and the
implementation of the first two formats is too buggy to be used).

Thus I think that the answer is pretty obvious here: we should try with
QEMU, whose supported format list is way wider.

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