[libvirt] [PATCH] lxc: return correct number of CPUs
When getting number of CPUs the host has assigned, there was always number "1" returned. Even though all lxc domains with no pinning launched by libvirt run on all pCPUs (by default, no matter what's the number), we should at least return the same number as the user specified when creating the domain. --- The bug addressed above will be managed later, because I believe this needs to be discussed first (we don't say that <vcpu> is not supported for lxc, but we are able to set only pinning, shares, not number of CPUs; due to using cgroups). The question will be: "Should we change the docs and ban it in the code or make some workaround for fixing it?" src/lxc/lxc_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 9aea556..33b2774 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -590,7 +590,7 @@ static int lxcDomainGetInfo(virDomainPtr dom, } info->maxMem = vm->def->mem.max_balloon; - info->nrVirtCpu = 1; + info->nrVirtCpu = vm->def->vcpus; ret = 0; cleanup: -- 1.7.8.6
On 05/29/2012 01:12 AM, Martin Kletzander wrote:
When getting number of CPUs the host has assigned, there was always number "1" returned. Even though all lxc domains with no pinning launched by libvirt run on all pCPUs (by default, no matter what's the number), we should at least return the same number as the user specified when creating the domain. --- The bug addressed above will be managed later, because I believe this needs to be discussed first (we don't say that <vcpu> is not supported for lxc, but we are able to set only pinning, shares, not number of CPUs; due to using cgroups). The question will be: "Should we change the docs and ban it in the code or make some workaround for fixing it?"
Is there no way to affect number of CPUs using just cgroups? If so, then I would lean towards erroring out if <vcpu> is specified but not equal to the number of host cpus. But like you say, that's a topic for a separate patch.
src/lxc/lxc_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 9aea556..33b2774 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -590,7 +590,7 @@ static int lxcDomainGetInfo(virDomainPtr dom, }
info->maxMem = vm->def->mem.max_balloon; - info->nrVirtCpu = 1; + info->nrVirtCpu = vm->def->vcpus;
ACK - this patch is safe to apply now. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 05/29/2012 06:39 PM, Eric Blake wrote:
On 05/29/2012 01:12 AM, Martin Kletzander wrote:
When getting number of CPUs the host has assigned, there was always number "1" returned. Even though all lxc domains with no pinning launched by libvirt run on all pCPUs (by default, no matter what's the number), we should at least return the same number as the user specified when creating the domain. --- The bug addressed above will be managed later, because I believe this needs to be discussed first (we don't say that <vcpu> is not supported for lxc, but we are able to set only pinning, shares, not number of CPUs; due to using cgroups). The question will be: "Should we change the docs and ban it in the code or make some workaround for fixing it?"
Is there no way to affect number of CPUs using just cgroups? If so, then I would lean towards erroring out if <vcpu> is specified but not equal to the number of host cpus. But like you say, that's a topic for a separate patch.
src/lxc/lxc_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 9aea556..33b2774 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -590,7 +590,7 @@ static int lxcDomainGetInfo(virDomainPtr dom, }
info->maxMem = vm->def->mem.max_balloon; - info->nrVirtCpu = 1; + info->nrVirtCpu = vm->def->vcpus;
ACK - this patch is safe to apply now.
Thanks, pushed. Martin
participants (2)
-
Eric Blake -
Martin Kletzander