|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libvirt, libxl and QDISKs
On Fri, 2013-04-26 at 11:10 +0100, Stefano Stabellini wrote:
> On Fri, 26 Apr 2013, Jim Fehlig wrote:
> > 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 the defaults are the same of libxl.
>
> However the mapping of RAW to TAP (libxl does the same) has always been
> a bit dubious to me: now that upstream QEMU is used with HVM guests too
> by libxl, there is no reason to use blktap over QEMU for raw files any
> more.
There are two TAP+RAW in the above, one is inside an if (driver="tap")
which seems reasonable, are you talking about the one in the
driver="file"?
I think it would be better for libvirt in the file and phy cases to just
say format=raw and leave libxl to pick a backend capable of providing
this.
Changing what libxl does is a separate question, but I think you are
right that a case could be made for preferring qdisk in the default
case.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |