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

[Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

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.

-- 
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

Attachment: 0001-libxl-allow-PHY-backend-for-files-allocate-loop-devi.patch
Description: Text Data

Attachment: signature.asc
Description: OpenPGP digital signature

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