[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libvirt, libxl and QDISKs
On 26/04/13 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. Qemu should indeed be much faster than blktap when using recent Linux kernels in the DomU due to persistent grants, I don't think blktap can provide the same performance, although I have not tested it. With Qemu we can get 900k IOPS. http://xenbits.xen.org/people/royger/persistent_read_qemu.png _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |