4:32 p.m.
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/
10:30 a.m.
Florian Forster wrote:
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?
Unfortunately no. The "memory" field is the amount of physical RAM
assigned to the virtual machine, and doesn't in any way reflect the
amount of memory that the virtual machine might actually be using. That
information is hidden in the guest's kernel so is only available to an
instance of collectd running inside the guest, and collectd already has
a plugin to get that (eg. src/memory.c). 'maxMem' is a peculiar Xen
thing to do with a guest's kernel requesting more memory from the
hypervisor, but it still doesn't reflect anything particularly
interesting about what (eg.) processes are doing inside the guest.
In any case, memory and maxMem are fixed numbers which only change when
the administrator issues specific management commands.
So we could certainly report these figures in collectd without problem,
but they're really not very interesting.
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'?
In theory yes, but because libvirt can't sample all these numbers in a
single atomic operation it's unlikely that they would add up this way in
practice.
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..
We can certainly remove the total from what is collected -- just delete
the code :-)
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 ;)
Yup, good plan. Do you need a patch for this or is it easier for you
just to delete the relevant code?
> 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.
Thanks,
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
6259
days inactive
6260
days old
1 comments
2 participants
participants (2)
-
Florian Forster -
Richard W.M. Jones