On Thu, Jun 07, 2018 at 01:59:11PM +0200, Michal Privoznik wrote: > Problem is, if there is a long standing job on a domain fetching > statistics might hiccup which might be a problem for mgmt apps that > query stats every few seconds. > > Orthogonal to this, I think we should break our sync QEMU_JOB_* into two > separate jobs: one for qemu monitor the other for qemu guest agent. > Problem is, if thread A grabs QEMU_JOB_MODIFY and talks only to guest > agent it prevents thread B from grabbing QEMU_JOB_QUERY which wants to > talk only to qemu monitor. But this is a different can of worms and I > haven't thought it through completely just yet. Yeah, I think that is important todo because the guest agent is untrusted service and so can arbitrarily delay its response to libvirt. Even though we timeout the agent after a while, we shouldn't really let it delay other APIs using the monitor. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
