[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] libxl: fix cdrom default driver name

On 07/18/2017 11:10 AM, Laine Stump wrote:
On 07/17/2017 10:42 AM, Christian Ehrhardt wrote:
In recent libvirt libxl does fill non-existant driver elements with type='raw',
but lacks the name='qemu' attribute that it had in the past.
Without that the xml fails to validate, therefore old XML files can't be
edited/defined anymore.

Since the cdrom device type only works with the qemu driver, add that as
the default attribute just as it was added in the past.

Example of the verification error:
   $ virt-xml-validate mytest.xml
   Relax-NG validity error : Extra element devices in interleave

Signed-off-by: Christian Ehrhardt <christian ehrhardt canonical com>
  src/libxl/libxl_domain.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 68a501c..70ddcea 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -367,8 +367,9 @@ libxlDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
          int actual_type = virStorageSourceGetActualType(disk->src);
          int format = virDomainDiskGetFormat(disk);
- /* for network-based disks, set 'qemu' as the default driver */
-        if (actual_type == VIR_STORAGE_TYPE_NETWORK) {
+        /* for network-based disk and cdrom, set 'qemu' as the default driver */
+        if (actual_type == VIR_STORAGE_TYPE_NETWORK ||
+            disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM) {
              if (!virDomainDiskGetDriver(disk) &&
                  virDomainDiskSetDriver(disk, "qemu") < 0)
                  return -1;

So is it the case that libxl never uses this attribute, and it's just
being added to the config in order to pass RNG validation? If so, then
my opinion would be that the RNG is too strict, and that attribute
should be made optional.

Yep, agreed. I'd rather relax the RNG than restrict CDROM devices to the qemu backend. Although IIRC qemu is currently the only usable backend wrt eject and other CDROM-specific operations, blkback should be able to read them just fine. And perhaps another CDROM backend will appear in Xen in the future. Instead of forcing the qemu backend here, I've sent a patch to relax the RNG



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]