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.

Michal Privoznik (5):
  qemu_domain: Document qemuDomainObjBeginJob
  qemuDomainObjBeginJobInternal: Remove spurious @ret assignment
  qemu_domain: Introduce qemuDomainObjBeginJobInstant
  Introcude VIR_CONNECT_GET_ALL_DOMAINS_STATS_BEST_EFFORT
  virsh: Introduce --best-effort to domstats

 include/libvirt/libvirt-domain.h |  1 +
 src/libvirt-domain.c             | 10 +++++++++
 src/qemu/qemu_domain.c           | 47 ++++++++++++++++++++++++++++++++++------
 src/qemu/qemu_domain.h           |  4 ++++
 src/qemu/qemu_driver.c           | 15 ++++++++++---
 tools/virsh-domain-monitor.c     |  7 ++++++
 tools/virsh.pod                  | 16 +++++++++-----
 7 files changed, 85 insertions(+), 15 deletions(-)

-- 
2.16.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 06/07/2018 02:53 PM, Daniel P. Berrangé wrote:
> 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.

Indeed. I'm working on it as we speak. Nevertheless, these patches are
independent of that (in case any reviewer is waiting for those patches
first).

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list