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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list