[libvirt] [PATCH 0/2] qemu: Rework CD/DVD changing

[Li Wei]

On 05/17/2013 04:52 PM, Michal Privoznik wrote:
> On 17.05.2013 10:16, Li Wei wrote:
>> On 05/17/2013 04:07 PM, Michal Privoznik wrote:
>>> On 17.05.2013 07:47, Li Wei wrote:
>>>> Hi Michal, Daniel
>>>>
>>>> It seems there is something wrong with the 2/2 part of this patchset.
>>>> When I do an "change-media" command in virsh, it doesn't do any better
>>>> than before, but even worse(I must to wait 5 secs to see the error).
>>>>
>>>> I'm not family with libvirt, just add some log things in the qemu_hotplug.c
>>>> and found the tray_status never change to open, but with michal's original
>>>> patch (which do active poll on tray_status), I can do "change-media" successfully
>>>> every time.
>>>
>>> Yes & no. Thing is - originally we ignored tray status in the guest. So
>>> in case guest has locked the tray and thus ignored our eject request, we
>>> have changed the media anyway, resulting in possible I/O errors within
>>> guest.
>>>
>>> With my patch, we send eject request to the qemu, and actively poll for
>>> the tray to open. We check for up to 10 times every 200ms. So guest has
>>> 2 seconds to open the tray. If the guest doesn't eject media and open
>>> the tray we don't proceed with forcibly changing the media.
>>>
>>> These patches are actually a bug fix for
>>> https://bugzilla.redhat.com/show_bug.cgi?id=892289
>>
>> Hmm... I think you misunderstood my meaning(sorry for my pool english),
>> simply to say, I can get expected behavior by apply patch V1 but not V2.
>>
>> In V1, we do active poll on qemuMonitorGetBlockInfo(), and in V2 we just
>> wait for origdisk->tray_status to become VIR_DOMAIN_DISK_TRAY_OPEN but
>> this never happened.
>>
>> Thanks,
>> Wei
> 
> Aaah, now I understand. So you are saying that the event is not being
> delivered. What's the qemu version?


I have the following version:

virsh # version
Compiled against library: libvirt 1.0.5
Using library: libvirt 1.0.5
Using API: QEMU 1.0.5
Running hypervisor: QEMU 1.4.1

> 
> If you turn the debug logs on, do you see DEVICE_TRAY_MOVED in them?
> http://wiki.libvirt.org/page/DebugLogs
> 
> Or maybe the timeout is just short for your guest to eject the tray. So
> after a while, does 'virsh change-media' succeed?

Yes, I can see the DEVICE_TRAY_MOVED in the log file, it goes after
the debug message "qemuDomainChangeEjectableMedia:103 : Waiting 500ms for tray to open. Retries left 0".
does that mean the timeout is too short? 

If the guest needs too much time to eject, I'm wondering why when I use
the v1 patch, I can get succeed in about 1 to 2 seconds. I doubt if there
are other problems cause tray_status not updated in time?

I appended the log file for your reference, if you need any other information,
please tell me.

Thanks,
Wei

> 
> Michal
> 
>>
>>>
>>>>
>>>> IMHO, there must be some bug in the processing of qemu tray change.
>>>>
>>>> Thanks,
>>>> Wei
>>>>
>>>>
>>>> On 01/25/2013 08:20 PM, Michal Privoznik wrote:
>>>>> The first patch is bare bug fix (without any bug reported though).
>>>>> The second is again a bug fix, but not so easy to spot. Basically, when we
>>>>> change a media, we should issue 'eject' first, then wait until the tray gets
>>>>> open, after which we can finally issue 'change' command. Even for bare 'eject'
>>>>> we ought to check status, shouldn't we?
>>>>>
>>>>> Michal Privoznik (2):
>>>>>   qemu_monitor: Fix tray-open attribute in query-block
>>>>>   qemu_hotplug: Rework media changing process
>>>>>
>>>>>  src/qemu/qemu_hotplug.c      | 51 +++++++++++++++++++++++++++++++++++++++++---
>>>>>  src/qemu/qemu_monitor_json.c |  2 +-
>>>>>  src/qemu/qemu_monitor_text.c |  6 +++---
>>>>>  3 files changed, 52 insertions(+), 7 deletions(-)
>>>>>
>>>
>>>
>>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvirtd.log
Type: text/x-log
Size: 42795 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130517/7771d9de/attachment-0001.bin>