From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: libvirt, libxl and QDISKs Date: Thu, 25 Apr 2013 19:27:16 -0600 Message-ID: <5179D7F4.2080408@suse.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> <51792E1F.3030005@eu.citrix.com> <1366898215.20256.552.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1366898215.20256.552.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 , Stefano Stabellini , Dave Scott , xen-devel List-Id: xen-devel@lists.xenproject.org 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; break; default: virReportError(VIR_ERR_INTERNAL_ERROR, _("libxenlight does not support disk driver %s"), virStorageFileFormatTypeToString(l_disk->format)); return -1; } } else if (STREQ(l_disk->driverName, "file")) { x_disk->format = LIBXL_DISK_FORMAT_RAW; x_disk->backend = LIBXL_DISK_BACKEND_TAP; } else if (STREQ(l_disk->driverName, "phy")) { x_disk->format = LIBXL_DISK_FORMAT_RAW; x_disk->backend = LIBXL_DISK_BACKEND_PHY; } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("libxenlight does not support disk driver %s"), l_disk->driverName); return -1; } } else { /* * If driverName is not specified, default to raw as per * xl-disk-configuration.txt in the xen documentation and let * libxl pick a suitable backend. */ x_disk->format = LIBXL_DISK_FORMAT_RAW; x_disk->backend = LIBXL_DISK_BACKEND_UNKNOWN; } > >> 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? > >> 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, unless you were using a minimal configuration and letting the individual hypervisor driver choose defaults. It would probably work with raw images and no driver element defined, e.g.