Hi, Eric
On Fri, 01 Apr 2011 10:19:20 -0600
Eric Blake <eblake(a)redhat.com> wrote:
On 03/31/2011 07:55 PM, Minoru Usui wrote:
> virNodeGetCpuTime: Expose new API
>
> include/libvirt/libvirt.h.in | 26 ++++++++++++++++++++++++++
> src/libvirt_public.syms | 1 +
> 2 files changed, 27 insertions(+), 0 deletions(-)
>
> +/**
> + * virNodeCpuTime:
> + *
> + * a virNodeCpuTime is a structure filled by virNodeGetCpuTime() and providing
> + * the information for the cpu time of Node.
> + */
> +
> +typedef struct _virNodeCpuTime virNodeCpuTime;
> +
> +struct _virNodeCpuTime {
> + unsigned long long user;
> + unsigned long long system;
> + unsigned long long idle;
> + unsigned long long iowait;
> +};
Can we portably get all of this information on Windows? If not, how do
you express which values we don't know how to obtain?
> @@ -593,6 +616,9 @@ int virNodeGetInfo (virConnectPtr
conn,
> virNodeInfoPtr info);
> char * virConnectGetCapabilities (virConnectPtr conn);
>
> +int virNodeGetCpuTime (virConnectPtr conn,
> + virNodeCpuTimePtr cpu_time);
> +
Rather than locking ourselves into yet another inflexible API (no flags
parameter and a hard-coded struct means no way to extend this if we ever
come up with some new stat to query), should we instead be following the
lead of getMemoryParameters which takes a typed-name/value array to pass
an arbitrary number of parameters, which allows extension without a new API?
OK.
I'll change its user I/F like virDomainGetMemoryParameters(),
if it doesn't return absolute CPU time values.
> +++ b/src/libvirt_public.syms
> @@ -434,6 +434,7 @@ LIBVIRT_0.9.0 {
> virEventRunDefaultImpl;
> virStorageVolDownload;
> virStorageVolUpload;
> + virNodeGetCpuTime;
> } LIBVIRT_0.8.8;
While I think that something along the lines of this API is appropriate
for libvirt (indeed, knowing a host's CPU utilization can indeed be a
factor for upper-level management software in deciding whether to
migrate another domain on or off of the machine), it's too late to put
it into 0.9.0. We'd be setting bad precedent by accepting this after
the first release candidate did a feature freeze, so you'd need to
adjust this to 0.9.1.
OK.
I'll change it.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org
--
Minoru Usui <usui(a)mxm.nes.nec.co.jp>