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

[David Scott <dave.scott@xxxxxxxxxxxxx>]

On 25/04/13 13:43, Ian Campbell wrote:
> On Thu, 2013-04-25 at 13:12 +0100, Dave Scott wrote:
> > On 25/04/13 12:57, Ian Campbell wrote:
> > > On Thu, 2013-04-25 at 12:55 +0100, Stefano Stabellini wrote:
> > >
> > > > 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?
> > > That's not quite the original question because in that case it was raw,
> > > at least as far as the libxl interface is concerned.
> > >
> > > > 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.
> > > Which I think we do, we only try and use blktap for raw and vhd.
> > As well as the disk format dimension (vhd, qcow2 etc) there's also the
> > network disk access protocol (iSCSI, ceph/RBD, sheepdog?). Although both
> > blktap/tapdisk can handle raw, alas all the interesting (perhaps I'm
> > showing my bias here ;-) disk access protocols are in qemu. So if we
> > default to blktap/tapdisk we can only handle raw *files*, whereas if we
> > default to qemu we can also do these new fancy things as well.
> Remind me why you can't specify backend=qdisk explicitly? Does libvirt
> not propagate anything like that?
I'll give this a go tomorrow when I'm not at the mercy of dodgy wifi :-) 
From my reading of the libvirt code it does allow the selection of a 
driverName from the set "tap" "tap2" "file" and "phy". It looks like we 
could define a "qdisk" driverName.
Actually this reminds me of a general concern I had: I worry that people 
who choose to use libvirt will likely use all the default options, and 
not customise their code too much for a specific hypervisor. After all, 
if they wanted to customise their code for xen they would just use libxl 
and use the richer interface. I think we ought to make sure as much 
stuff just works by default as possible. In my ideal world it would be 
possible to take a simple libvirt domain configuration (perhaps one 
which used to run on kvm) and run it on xen, transparently benefiting 
from xen features such as driver domains (and automatic blktap/qemu 
selection?). I think if the domain XML requires too much tweaking then 
people will just not use the features or may give up altogether.
Cheers,
Dave

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