Hi Rich, as promised, I've taken a more in-depth look at the `libvirtstats' plugin (I've adopted this as a working title for now and will do the renaming on the weekend or so..) and it looks very good, thanks again :) The `_virDomainInfo' structure has the members `memory' and `maxMem'. Can one calculate `unused' or `free' (or whatever the preferred term in this particular case is) memory using `maxMem - memory'? Would that be an interesting metric? I'm not sure what the best way to store the CPU usage is. Is the `cpuTime' member of the `_virDomainInfo' structure the same as the sum over all `(struct _virVcpuInfo).cpuTime'? Does collecting the total make sense in this case? I'd much rather use the same `type' for ``normal'' CPU statistics and this case which would be much simpler if we didn't collect the total.. I've done some minor things while looking through the code. It basically a mix of coding style and personal convention. Since there's no Debian package yet I didn't install try to compile it yet. I'll install the library and fix the errors I've made as soon as I have some more spare time. The things I've changed are basically: - Rather use `sizeof (array);' than the `DATA_MAX_NAME_LEN' define. - NULL-terminate the strings unconditionally after `strncpy' or `snprintf' was used. - Rather use -- 8< -- if (status != 0) { handle_error (); } -- >8 -- than -- 8< -- if (status == -1) { handle_error (); } -- >8 -- On Mon, Nov 05, 2007 at 02:00:12PM +0000, Richard W.M. Jones wrote:
In the types.db, I have set the max for virt_cpu_total to be 256,000,000,000. [...] Therefore I have assumed here that max CPUs = 256.
That's basically the reason why I'd rather collect each virtual CPU in a separate file and ``simply'' combine the graphs. This will work for n+1 CPUs ;)
I'm using CSV output, which works, but it seems to report the aggregate counter values instead of the differences. Is that to be expected?
Yes, that is expected. The changes I've made for the next feature release (4.3) include an easy way to get the rates for a counter value. So I will certainly add an option to store rates instead. Regards, -octo -- Florian octo Forster Hacker in training GnuPG: 0x91523C3D http://verplant.org/