On Tue, 27 Apr 2010 20:01:06 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Tue, Apr 27, 2010 at 03:50:20PM -0300, Luiz Capitulino wrote:
> On Tue, 27 Apr 2010 11:20:39 +0200
> jdenemar(a)redhat.com wrote:
>
> > From: Jiri Denemark <jdenemar(a)redhat.com>
> >
> > With JSON qemu monitor, we get a STOP event from qemu whenever qemu
> > stops guests CPUs. The downside of it is that vm->state is changed to
> > PAUSED and a new generic paused event is send to applications. However,
> > when we ask qemu to stop the CPUs we are not really interested in qemu
> > event and we usually want to issue a more specific event.
>
> Can you give an example? Say, "guest is suspended"?
>
> If this is the case, something you have to consider is whether libvirt
> should add high-level events on top of low-level ones.
>
> Or, to make it more general, what should libvirt report to applications
> wrt events?
>
> > By setting vm->status to PAUSED before actually sending the request to
> > qemu (and resetting it back if the request fails) we can ignore the
> > event since the event handler does nothing when the guest is already
> > paused. This solution is quite hacky but unfortunately it's the best
> > solution which I was able to come up with and it doesn't introduce a
> > race condition.
>
> You could extend the low-level driver to accept a mask of events to
> be ignored.
The core problem here is that QEMU only emits a STOP event, with no
corresponding CONT event. If QEMU had been doing both, this patch
would not be neccessary, because we'd see both transitions from QEMU
instead of just one direction.
Oh, I already have a patch that introduces it, it's part of the
savevm/loadvm/delvm series (which is giving me a bit of headache ATM).
I will cherry-pick the patch and submit it later today.