Re: [RFC][scale] new API for querying domains stats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
> From: "Richard W.M. Jones" <rjones@xxxxxxxxxx>
> To: "Li Wei" <lw@xxxxxxxxxxxxxx>
> Cc: "Francesco Romani" <fromani@xxxxxxxxxx>, libvir-list@xxxxxxxxxx
> Sent: Tuesday, August 12, 2014 11:04:05 AM
> Subject: Re:  [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

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]