From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Scott Subject: Re: libvirt, libxl and QDISKs Date: Thu, 25 Apr 2013 14:22:39 +0100 Message-ID: <51792E1F.3030005@eu.citrix.com> References: <5177EA93.7000403@eu.citrix.com> <1366880153.20256.432.camel@zakaz.uk.xensource.com> <1366889589.20256.510.camel@zakaz.uk.xensource.com> <1366891065.20256.517.camel@zakaz.uk.xensource.com> <51791DB1.9070903@eu.citrix.com> <1366893802.20256.526.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1366893802.20256.526.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: George Dunlap , xen-devel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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