[libvirt] [RFC][scale] new API for querying domains stats
Francesco Romani
fromani at redhat.com
Tue Aug 12 15:10:10 UTC 2014
----- Original Message -----
> From: "Richard W.M. Jones" <rjones at redhat.com>
> To: "Li Wei" <lw at cn.fujitsu.com>
> Cc: "Francesco Romani" <fromani at redhat.com>, libvir-list at redhat.com
> Sent: Tuesday, August 12, 2014 11:04:05 AM
> Subject: Re: [libvirt] [RFC][scale] new API for querying domains stats
>
[...]
> > > Is it possible to design an API that can work across all domains
> > > in a single call?
> >
> > How about the following API:
> >
> > int virConnectGetAllBlockStats(virConnectPtr conn,
> > virDomainPtr domain,
> > virDomainBlockBulkStatsPtr *stats,
> > unsigned int flags);
> > @conn: pointer to libvirt connection
> > @domain: pointer to the domain to be queried, NULL for all domains
> > @stats: array of virDomainBlockBulkStats struct(see below) to be populated
> > @flags: filter flags
> > Return the number of virDomainBlockBulkStats populated.
> >
> > where virDomainBlockBulkStats defined as:
> >
> > struct _virDomainBlockBulkStats {
> > virDomainPtr domain; /* domain the block stats belongs to */
> > virTypedParameterPtr params; /* params to store block stats */
> > unsigned int nparams; /* how many params used for each block stats */
> > unsigned int ndisks; /* how many block stats in this domain */
> > };
>
> Works for me.
Same here.
oVirt, more specifically VDSM, needs to check all the stats of all
the domains on a given host at once, so this API should fit the task.
Since VDSM takes ownership (read: keep track and control) of all the VMs,
the filtering capability of this new API should be good enough.
+++
It would be nice, but less important, to be able to somehow reuse the
`stats' argument.
What I'm looking here is a way to avoid to allocate/deallocate every time
all the needed structure before and after each call.
I'm saying so because is a pretty common scenario for a VM (at least in
the cases I'm aware of) to have the same number of disks during all its life.
But I believe this is an optimization which can be added later.
Thanks,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
More information about the libvir-list
mailing list