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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Ian



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