[libvirt] [PATCH] qemu: hotplug: Report error if we hit tray status timeout

[Cole Robinson]

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