On 05/17/2016 04:39 AM, Michal Privoznik wrote:
> 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.
>
Thanks, I pushed with those changes
> 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.
>
Seems to be a qemu regression between v2.5.0 and v2.6.0, I'm bisecting now
Thanks,
Cole
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list