[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.