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

[Michal Privoznik]

On 17.05.2016 14:19, Cole Robinson wrote:
> 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
> 

That's rather unpleasant. How is libvirt supposed to know when device
tray has moved then?

Michal