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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 26 Apr 2013, Marek Marczykowski wrote:
> On 26.04.2013 12:10, 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.
> 
> What about old good loop+phy based backend for file disk images? I don't want
> whole qemu in dom0 for PV domains, only for handling simple disk backend.
> Additionally sparse images + loop + phy + mount -o discard in domU makes the
> images "auto shrinking". Don't know if qemu is able to do this.
> 
> Attached patch, which I currently use for that. If it is close to something
> that would be accepted, I will send it in new thread.
> 
> BTW I don't want qemu in dom0 for HVM also, but this is another story
> (modified stubdom etc) and probably not acceptable in vanilla xen.

The original reason to drop loop+phy from libxl was that it is not safe
as it doesn't support O_DIRECT. It always goes through the Linux page
cache.
However after a lengthy discussion regarding QEMU and O_DIRECT with
Alex, it turns out that we don't actually need O_DIRECT for data
consistency so loop+phy should be safe too after all.

Time to bring back loop support?

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