Re: [libvirt] [PATCH] Add RESUME event listener to qemu monitor.
On Jan 15, 2013, at 5:13 PM, Eric Blake <eblake(a)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(a)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