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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-04-26 at 02:27 +0100, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Thu, 2013-04-25 at 14:22 +0100, Dave Scott wrote:
> >   
> >> 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".
> >>     
> >
> > In libxl the choices are phy, tap and qdisk. There's no file nor any
> > distinction between tap and tap2. I expect the libxl libvirt driver is
> > trying to make things easier for people migrating from xend (which is
> > to be applauded).
> >   
> 
> Right.  'file' is mapped to backend 'tap' and format 'raw'.  In fact, I
> should just post the code here for review :).  For a bit of context,
> l_disk is libvirt's definition, and x_disk is libxl's.  Comments on this
> mapping welcome, keeping in mind Ian's point about migrating from xend.
> 
>     if (l_disk->driverName) {
>         if (STREQ(l_disk->driverName, "tap") ||
>             STREQ(l_disk->driverName, "tap2")) {
>             switch (l_disk->format) {
>             case VIR_STORAGE_FILE_QCOW:
>                 x_disk->format = LIBXL_DISK_FORMAT_QCOW;
>                 x_disk->backend = LIBXL_DISK_BACKEND_QDISK;
>                 break;
>             case VIR_STORAGE_FILE_QCOW2:
>                 x_disk->format = LIBXL_DISK_FORMAT_QCOW2;
>                 x_disk->backend = LIBXL_DISK_BACKEND_QDISK;
>                 break;
>             case VIR_STORAGE_FILE_VHD:
>                 x_disk->format = LIBXL_DISK_FORMAT_VHD;
>                 x_disk->backend = LIBXL_DISK_BACKEND_TAP;
>                 break;
>             case VIR_STORAGE_FILE_NONE:
>                 /* No subtype specified, default to raw/tap */
>             case VIR_STORAGE_FILE_RAW:
>                 x_disk->format = LIBXL_DISK_FORMAT_RAW;
>                 x_disk->backend = LIBXL_DISK_BACKEND_TAP;
[...]
> >> It looks like we could define a "qdisk" driverName.
> >>     
> >
> > Yes, I think this would work. WRT to your comment below it looks like
> > other libvirt drivers call this driver "qemu".
> >   
> 
> IMO, we should just extend the above to map driverName 'qemu' to backend
> 'qdisk'.  But what about the formats?  I though qdisk could handle all
> of them, particularly with qemu-upstream, even vmdk?

We could certainly add new LIBXL_DISK_FORMAT_FOO to expose other
formats, such as VMDK and the presumably these would map naturally from
the VIR_STORAGE namespace.

I think for qdisk you want a switch much like the above, but the backend
always qdisk.

I could also see an argument for handling the case of an unknown (or
NIL) driver name by defaulting backend to UNKNOWN and setting the format
as best you are able, like you do for tap (and soon qdisk ;-)).

In addition are we at liberty to define driverName="xl" which explicitly
tells us that source file == the full xl spec (which I suppose is really
the xlu spec or something), using the libxlu_disk parser?

Perhaps having LIBXL_DISK_FORMAT as an enum was a mistake and really it
should have been a string with a mapping to backends in a configuration
file, so it could be extensible without needing to recompile the
library. This could be something to consider for a future libxl.

> >> 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.
> >>     
> >
> > This would be ideal, I seem to remember hearing that disk configuration
> > was something which libvirt didn't abstract, tending to just expose
> > underlying configuration strings of the underlying toolstack. So this is
> > one area where you actually have to change things when you migrate
> > between hypervisors or they won't work at all.
> >   
> 
> For the most part, that is true,

Glad to hear I'm not telling too blatant lies ;-)

Ian.


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