[libvirt] [RFC][scale] new API for querying domains stats

Francesco Romani fromani at redhat.com
Tue Jul 1 07:09:13 UTC 2014


Hi everyone,

I'd like to discuss possible APIs and plans for new query APIs in libvirt.

I'm one of the oVirt (http://www.ovirt.org) developers, and I write code for VDSM;
VDSM is the node management daemon, which is in charge, among many other things, to
gather the host and statistics per Domain/VM.

Right now we aim for a number of VM per node in the (few) hundreds, but we have big plans
to scale much more, and to possibly reach thousands in a not so distant future.
At the moment, we use one thread per VM to gather the VM stats (CPU, network, disk),
and of course this obviously scales poorly.

This is made only worse by the fact that VDSM is a python 2.7 application, and notoriously
python 2.x behaves very badly with threads. We are already working to improve our code,
but I'd like to bring the discussion here and see if and when the querying API can be improved.

We currently use these APIs for our sempling:
  virDomainBlockInfo
  virDomainGetInfo
  virDomainGetCPUStats
  virDomainBlockStats
  virDomainBlockStatsFlags
  virDomainInterfaceStats
  virDomainGetVcpusFlags
  virDomainGetMetadata

What we'd like to have is

* asynchronous APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113106)
  This would be just awesome. Either a single callback or a different one per call is fine
  (let's discuss this!).
  please note that we are much more concerned about thread reduction then about performance
  numbers. We had report of thread number becoming a real harm, while performance so far
  is not yet a concern (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54)

* bulk APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113116)
  would be really welcome as well. It is quite independent from the previous bullet point
  and would help us greatly with scale.

So, I'd like to discuss if these additions are (or can be) in the project roadmap,
and, if so, how the API could look like and what the possible timeframe could be.
Of course I'd be happy to provide any further information about VDSM and its workings.

Thoughts very welcome!

Thanks and best regards,

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani




More information about the libvir-list mailing list