On Thu, Oct 26, 2017 at 10:21:17 +0530, Prerna wrote: > On Wed, Oct 25, 2017 at 4:12 PM, Jiri Denemark <jdenemar@xxxxxxxxxx> wrote: > > On Tue, Oct 24, 2017 at 10:34:53 -0700, Prerna Saxena wrote: [...] > > > Patch Series status: > > > Strictly RFC only. No compilation issues. I have not had a chance to > > > (stress) test it after rebase to latest master. > > > Note that documentation and test coverage is TBD, since a few open > > > points remain. > > > > > > Known issues/ caveats: > > > - RPC handling time will become non-deterministic. > > > - An event will only be "notified" to a client once the RPC for same VM > > completes. > > > - Needs careful consideration in all cases where a QMP event is used to > > > "signal" an RPC thread, else will deadlock. > > > > This last issue is actually a show stopper here. We need to make sure > > QMP events are processed while a job is still active on the same domain. > > Otherwise thinks kile block jobs and migration, which are long running > > jobs driven by events, will break. > > > > Jirka > > > Completely agree, which is why I have explicitly mentioned this. > However, I do not completely follow why it needs to be this way. Can the > block job APIs between QEMU <--> libvirt be fixed so that such behaviour is > avoided ? Not really. Events from qemu are a big improvement from the times when we were polling for state of jobs. Additionally migration with storage in libvirt uses blockjobs which are asynchronous in qemu but libvirt needs to wait for them synchronously. Since blockjobs in qemu need to be asynchronous (they take a long time and libvirt needs to be able to use the monitor meanwhile) requires us to do handling of incomming events while a libvirt API is active.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
