在 2012年4月17日 上午4:11，Eric Blake <eblake@redhat.com> 写道：
On 04/16/2012 05:37 AM, Zhihua Che wrote:
I thought this value store the run time of the cpu since last boot.
The intent is to store run time of the hypervisor process managing the guest (which therefore is larger than the amount of time that the guest thinks it has been running, since the hypervisor has some overhead). But the API is flexible enough that we can add more statistics, if it proves easy to collect such additional statistics.
But I find I was wrong because this value would increase until it wraps down and doesn't reset even the domain is restarted.
How are you restarting the guest? If it is by rebooting the guest _within the same qemu process_, then no, the numbers won't reset. Based on how the cpuacct cgroup works, the numbers should only wrap when you actually create a new qemu process (actually stop the guest and boot it fresh in a new qemu process, rather than rebooting the guest within the same qemu process).
After reading your post, I did the below experiment again. I started the domain by issuing 'start ubuntu-1' and shutted down my domain by issuing 'destroy ubuntu-1'. (BTW, I cannot shutdown my domain by 'shutdown ubunut-1'. I guess my domain image got something wrong. I wish this didn't affect the experiment) Here are my two sample values. start ubunt-1 cpu0+cpu1 11239925290 cpu0 6034491893 cpu1 5205433307 destroy and start ubunu-1 cpu0+cpu1 10621566430 cpu0 5403373809 cpu1 5218192621 I can't determine whether these value reseted because total number is lower than that before restarting while one cpu is larger or lower. These values really confuse me. I check the kvm process id through ps. I'm sure the two running domain are assigned two different process id. I guess that means they run as different qemu process as you mentioned.
Perhaps we should be improving our XML to track delta usage since a given point in time, and when we detect a domain reboot, update that delta point so that the usage will again appear to be 0; allowing a delta calculation would also let us "track" CPU usage even across domain migration or managedsave/restore.
So, what does this value mean?
How can I get the CPU usage of the domain?
I found nothing on the API reference doc page:-(. No word is related with the meaning of the returned array of virTypedParameter by virDomainGetCPUStats().
I found this:
http://libvirt.org/html/libvirt-libvirt.html#VIR_DOMAIN_CPU_STATS_CPUTIME
"cpu usage in nanoseconds, as a ullong"
and looking at libvirt.h, VIR_DOMAIN_CPU_STATS_CPUTIME maps to the "cpu_time" name of your API call.
If that still isn't enough information, could you help out by submitting patches to improve our documentation?
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org