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.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|