Re: libvirt, libxl and QDISKs

[David Scott <dave.scott@eu.citrix.com>]

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