On Fri, Aug 10, 2007 at 01:59:34PM +0100, Richard W.M. Jones wrote:
> It was suggested to me that we should provide a way to return bytes read
> and written on block devices (not just requests). Xen doesn't support
> that however, so I have also changed the fields in this structure so
> that they can be returned set to -1 to indicate "no data / not supported".
yeah, it's better to have both when you can because being able to detect
change in average block size transfer is important too from a monitoring
perspective.
> The updated stats structures are shown below.
>
> Rich.
>
> /* Block device stats for virDomainBlockStats.
> *
> * Hypervisors may return a field set to (int64_t)-1 which indicates
> * that the hypervisor does not support that statistic.
> */
> struct _virDomainBlockStats {
> int64_t rd_req;
> int64_t rd_bytes;
> int64_t wr_req;
> int64_t wr_byes;
wr_bytes :-)
> int64_t errs; // In Xen this returns the mysterious 'oo_req'.
> };
> typedef struct _virDomainBlockStats *virDomainBlockStatsPtr;
then yes that's okay.
Those interfaces are what I suggested as the low level ones, I guess
they are needed even if tehy don't really scale as the number of
domain and more importantly the number of node increases. But it allows
to build higher level monitoring implementations.
My current POV based on previous monitoring work is that if you are monitoring
up to a few dozen machines then aggregating the data to the monitoring
application is fine, where you can then apply the user based policy to
raise the events (and subsequent rules or UI alerts), but if you want
to scale you have to export the monitoring down to each node, and push
the policies there, just gathering the events/alerts at the monitoring
application or console level.
In any case having the low level API is needed so something like those
entry points are needed.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list