Re: [PATCH v1] numa: compute and set matching vcpus for numa domains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 20, 2017 at 11:29:26AM +0200, Wim Ten Have wrote:
> From: Wim ten Have <wim.ten.have@xxxxxxxxxx>
> 
> The QEMU driver can erroneously allocate more vpus to a domain
> than there are cpus in the domain if the <numa> element is used
> to describe <cpu> element topology. Fix this by calculating
> the number of cpus described in the <numa> element of a <cpu>
> element and comparing it to the number of vcpus. If the number
> of vcpus is greater than the number of cpus, cap the number of
> vcpus to the number of cpus.
> 
> This patch also adds a small libvirt documentation update under
> the "CPU Allocation" section.
> 
> Signed-off-by: Wim ten Have <wim.ten.have@xxxxxxxxxx>
> ---
>  docs/formatdomain.html.in |  9 ++++++++-
>  src/conf/domain_conf.c    | 14 +++++++++++---
>  2 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index 07208ee..3c85307 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -501,7 +501,14 @@
>        <dt><code>vcpu</code></dt>
>        <dd>The content of this element defines the maximum number of virtual
>          CPUs allocated for the guest OS, which must be between 1 and
> -        the maximum supported by the hypervisor.
> +        the maximum supported by the hypervisor. If a <code>numa</code>
> +        element is contained within the <code>cpu</code> element, the
> +        number of virtual CPUs to be allocated is compared with the sum
> +        of the <code>cpus</code> attributes across the <code>cell</code>
> +        elements within the <code>numa</code> element. If the number of
> +        virtual CPUs is greater than the sum of the <code>cpus</code>
> +        attributes, the number of virtual CPUs is capped at sum of the
> +        <code>cpus</code> attributes.
>          <dl>
>           <dt><code>cpuset</code></dt>
>           <dd>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 958a5b7..73d7f4f 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -3844,12 +3844,20 @@ virDomainDefPostParseMemory(virDomainDefPtr def,
>      unsigned long long numaMemory = 0;
>      unsigned long long hotplugMemory = 0;
>  
> -    /* Attempt to infer the initial memory size from the sum NUMA memory sizes
> -     * in case ABI updates are allowed or the <memory> element wasn't specified */
> +    /* Attempt to infer the initial memory size from the sum NUMA memory
> +     * sizes in case ABI updates are allowed or the <memory> element
> +     * wasn't specified.  Also cap the vcpu count to the sum of NUMA cpus
> +     * allocated for all nodes. */
>      if (def->mem.total_memory == 0 ||
>          parseFlags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE ||
> -        parseFlags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION)
> +        parseFlags & VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION) {
> +        unsigned int numaVcpus = 0;
> +
> +        if ((numaVcpus = virDomainNumaGetCPUCountTotal(def->numa)))
> +            virDomainDefSetVcpus(def, numaVcpus);
> +
>          numaMemory = virDomainNumaGetMemorySize(def->numa);
> +    }

AFAICT, this scenario is simply a user configuration mistake, and so we
should report an error message to them to fix it.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux