On 12/11/14 08:43, Francesco Romani wrote:
This patch adds the information about the physical cpu
placement of virtual cpus for bulk stats.
This is the only difference in output with the
virDomainGetVcpus() API.
Management software, like oVirt, needs this information
to properly manage NUMA configurations.
Are you sure that you are getting what you expect? When this stats group
was first implemented I asked not to include this stat as it only shows
the actual host cpu id where the guest cpu is running at that precise
moment. The problem with that is that usual configurations don't map the
cpus in a 1:1 fashion, but rather allow a specific guest CPU to be run
on a subset of host cpus according to it's scheduling decisions.
That means that the stat might oscillate in the given set where the
guest vcpu is pinned at. Could you please share your use case for this
one? I'm curious to see whether you have some real use of such data.
Signed-off-by: Francesco Romani <fromani(a)redhat.com>
Peter
---
src/libvirt-domain.c | 2 ++
src/qemu/qemu_driver.c | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index cb76d8c..e84f6a8 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -10888,6 +10888,8 @@ virConnectGetDomainCapabilities(virConnectPtr conn,
* from virVcpuState enum.
* "vcpu.<num>.time" - virtual cpu time spent by virtual CPU
<num>
* as unsigned long long.
+ * "vcpu.<num>.physical" - real CPU number on which virtual CPU
<num> is
+ * running, as int. -1 if offline.
*
* VIR_DOMAIN_STATS_INTERFACE: Return network interface statistics.
* The typed parameter keys are in this format:
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 830fca7..b62cabf 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -18348,6 +18348,15 @@ qemuDomainGetStatsVcpu(virQEMUDriverPtr driver
ATTRIBUTE_UNUSED,
param_name,
cpuinfo[i].cpuTime) < 0)
goto cleanup;
+
+ snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH,
+ "vcpu.%zu.physical", i);
+ if (virTypedParamsAddInt(&record->params,
+ &record->nparams,
+ maxparams,
+ param_name,
+ cpuinfo[i].cpu) < 0)
+ goto cleanup;
}
ret = 0;
Patch looks good though.