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/
Attachment:
signature.asc
Description: Digital signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list