[libvirt] [PATCH] Add RESUME event listener to qemu monitor.

[Andres Lagar-Cavilla]

On Jan 15, 2013, at 5:13 PM, Eric Blake <eblake at redhat.com> wrote:

> On 01/07/2013 02:25 PM, Andres Lagar-Cavilla wrote:
>> Perform all the appropriate plumbing.
>> 
>> When qemu/KVM VMs are paused manually through a monitor not-owned by libvirt,
>> libvirt will think of them as "paused" event after they are resumed and
>> effectively running. With this patch the discrepancy goes away.
>> 
>> This is meant to address bug 892791.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres at lagarcavilla.org>
>> ---
>> src/qemu/qemu_monitor.c      |   10 ++++++++
>> src/qemu/qemu_monitor.h      |    3 +++
>> src/qemu/qemu_monitor_json.c |    7 ++++++
>> src/qemu/qemu_process.c      |   56 ++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 76 insertions(+)
> 
> Thanks again for insisting on this patch; it turns out that it solved a
> very real problem with 'virsh block-copy --wait --pivot ...', 'virsh
> dump --live', and 'virsh create-snapshot-as --live --memspec ...', for
> upper level applications (like VDSM) that were tracing domain state
> solely through libvirt events rather than through querying libvirt for
> its current idea of domain state.  See
> https://bugzilla.redhat.com/show_bug.cgi?id=894085 for details, and my
> analysis why this patch is necessary even when there is no external
> monitor and no use of unsupported qemu-monitor-command.

Always happy to be of service. Karma points, ka-chin ;)
> 
> It does make me wonder if we ought to audit all callers of
> qemuDomainStartCPUs/qemuDomainStopCPUs to be more robust if qemu were
> ever to change to emit events _after_ responding to 'stop' and 'cont'
> monitor commands, instead of the current (lucky) results that the event
> always appears on the monitor before the return value of the command.
> 
It has been floated around that one should not rely on any event ordering. I understand the qemu maintainer's motivation to not give the impression of stable interfaces where it's not relevant. However, from looking at qemu's code it would be actually harder to emit events out of order than the current state. So I don't think this is a pressing worry.

Cheers!
Andres
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>