On Tue, 27 Apr 2010 20:01:06 +0100 "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > On Tue, Apr 27, 2010 at 03:50:20PM -0300, Luiz Capitulino wrote: > > On Tue, 27 Apr 2010 11:20:39 +0200 > > jdenemar@xxxxxxxxxx wrote: > > > > > From: Jiri Denemark <jdenemar@xxxxxxxxxx> > > > > > > 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list