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

[Cole Robinson]

On 05/17/2016 08:10 AM, Cole Robinson wrote:
> 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
> 

Well I guess that explains it:

commit abb3e55b5b718d6392441f56ba0729a62105ac56
Author: Max Reitz <mreitz at redhat.com>
Date:   Fri Jan 29 20:49:12 2016 +0100

    Revert "hw/block/fdc: Implement tray status"

The cover letter here has an explanation:
http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg04471.html

- Cole