On 03.05.2016 01:09, Cole Robinson wrote:
If we exceed the timeout waiting for the tray status to change,
we don't report an error. Fix it
---
I hit this trying to eject floppy media for a win10 VM with F24
qemu, but I didn't dig deeper to figure out _why_ it's timing out...
src/qemu/qemu_hotplug.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 03e5309..e5f8a38 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -224,7 +224,13 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
goto error;
while (disk->tray_status != VIR_DOMAIN_DISK_TRAY_OPEN) {
- if (virDomainObjWaitUntil(vm, now + CHANGE_MEDIA_TIMEOUT) != 0)
+ int rc2 = virDomainObjWaitUntil(vm, now + CHANGE_MEDIA_TIMEOUT);
+ if (rc2 == 1) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("timed out waiting for "
+ "disk tray status update"));
+ }
+ if (rc2 != 0)
goto error;
}
} while (rc < 0);
Huh, funny; I've just got to the same problem producing nearly the same
patch. I'd rename rc2 to wait_rc and test it for begin greater than 0
instead of being exactly one. I know it's the same right now, but I
think it's more solid.
And for the 'lost' event - I guess it's a qemu bug. While I was
debugging, I ran 'query-block' monitor command and saw tray closed. So
I've ran 'virsh update-device' which opens the tray and it timed out,
just like in your case. So I ran 'query-block' again just to find that
tray is now being reported open. So there clearly has been a state
translation without qemu sending us corresponding event thus I'd call it
a qemu bug.
ACK
Michal