Qemu always opens the tray if forced to. Skip the waiting step in such case.
This also helps if qemu does not report the tray change event when opening the cdrom forcibly (the documentation says that the event will not be sent although qemu in fact does trigger it even if @force is selceted). This is a workaround for a qemu issue where qemu does not send the tray change event in some cases (after migration with empty closed locked drive) and thus renders the cdrom useless from libvirt's point of view. Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368368 --- src/qemu/qemu_hotplug.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index d13474a..48108fb 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -149,8 +149,7 @@ static int qemuHotplugWaitForTrayEject(virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainDiskDefPtr disk, - const char *driveAlias, - bool force) + const char *driveAlias) { unsigned long long now; int rc; @@ -175,7 +174,7 @@ qemuHotplugWaitForTrayEject(virQEMUDriverPtr driver, /* re-issue ejection command to pop out the media */ qemuDomainObjEnterMonitor(driver, vm); - rc = qemuMonitorEjectMedia(qemuDomainGetMonitor(vm), driveAlias, force); + rc = qemuMonitorEjectMedia(qemuDomainGetMonitor(vm), driveAlias, false); if (qemuDomainObjExitMonitor(driver, vm) < 0 || rc < 0) return -1; @@ -238,9 +237,9 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver, goto cleanup; /* If the tray is present and tray change event is supported wait for it to open. */ - if (diskPriv->tray && + if (!force && diskPriv->tray && virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE_TRAY_MOVED)) { - rc = qemuHotplugWaitForTrayEject(driver, vm, disk, driveAlias, force); + rc = qemuHotplugWaitForTrayEject(driver, vm, disk, driveAlias); if (rc < 0) goto error; } else { -- 2.9.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
