> > 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. > > > > 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. > > Hum, that sounds reasonnable, yes. All those operations should already > emit a more specific event, if that's the case, ACK. The only place where we don't emit any event after stopping CPUs is in qemudDomainCoreDump when making non-live dump. But we don't do that when talking to qemu using text monitor either. If we decide we should emit such event followed by a resume event after dump completes, we can make a separate patch for that. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list