[Libvir] Proposal: Block device and network stats

Richard W.M. Jones rjones at redhat.com
Fri Aug 10 13:58:59 UTC 2007


Daniel Veillard wrote:
>    wr_bytes :-)

Duh :-(

>>   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.

Agreed.

The other issue is remote, where we make 2 * nr_domains round trips. 
We're already making some k * nr_domains round trips to get the other 
info (eg. domain names, state, VCPU usage, ...) so there is an argument 
for being able to aggregate remote requests.  The easiest thing would 
seem to be to allow remote to pipeline requests and responses. 
Pipelining would get rid of the round trip delays.  The remote protocol 
allows pipelining already, but needs some mucky coding on top to make it 
actually work.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070810/dbe9247a/attachment-0001.bin>


More information about the libvir-list mailing list