Bug 1121295 - Odd vCPU topology dropped by libvirt
Summary: Odd vCPU topology dropped by libvirt
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.4.0
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
: 3.5.0
Assignee: Roy Golan
QA Contact: Ilanit Stein
URL:
Whiteboard: virt
: 1122014 (view as bug list)
Depends On: 1070890
Blocks: 1126797 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-07-18 22:46 UTC by Amador Pahim
Modified: 2019-04-28 09:52 UTC (History)
11 users (show)

Fixed In Version: vt2.2
Doc Type: Bug Fix
Doc Text:
Previously, the number of sockets configured for a virtual machine exceeded the QEMU limits. This caused the virtual machine to fail to run. Now, VDSM sends a proper socket value number according to configured limits inside the Engine (MaxNumOfVmSockets), so the virtual machine runs with a proper CPU topology that meets the vCPU required.
Clone Of:
: 1126797 (view as bug list)
Environment:
Last Closed: 2015-02-11 21:12:06 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0159 normal SHIPPED_LIVE vdsm 3.5.0 - bug fix and enhancement update 2015-02-12 01:35:58 UTC
oVirt gerrit 30594 master ABANDONED Fix xml maximum vcpus for odd number of vCores Never
oVirt gerrit 31029 ovirt-engine-3.5 MERGED core: pass MaxNumberOfSockets to create verb Never
oVirt gerrit 31032 ovirt-3.5 ABANDONED refine calculation of cpu topology Never
oVirt gerrit 31054 ovirt-engine-3.4 ABANDONED core: pass MaxNumberOfSockets to create verb Never
oVirt gerrit 31121 None None None Never
oVirt gerrit 31127 None None None Never
oVirt gerrit 31439 master MERGED core: maxVCpus revised Never
oVirt gerrit 31484 None None None Never

Description Amador Pahim 2014-07-18 22:46:40 UTC
Description of problem:
vdsm calculations to vcpu topology are creating topologies rejected by libvirt:

...
        <vcpu current="3">160</vcpu>
...
        <cpu match="exact">
                <model>Westmere</model>
                <topology cores="3" sockets="53" threads="1"/>
        </cpu>
...
Thread-34::ERROR::2014-07-18 16:33:27,746::vm::2286::vm.Vm::(_startUnderlyingVm) vmId=`a128612f-6ab0-4b8d-89ff-5585b5565605`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 2246, in _startUnderlyingVm
    self._run()
  File "/usr/share/vdsm/vm.py", line 3186, in _run
    self._connection.createXML(domxml, flags),
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 92, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2665, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: Maximum CPUs greater than topology limit


Version-Release number of selected component (if applicable):
vdsm-4.14.7-3.el6ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create and set "cores" with a number that 160 is not multiple of.
2. Start VM
3. Even approved by the CPU filter (which limites the vCPUS up to the Host physical CPUs number), the VM creation will fail due the unnacepted topology by libvirt.

Comment 1 Michal Skrivanek 2014-07-28 10:30:05 UTC
*** Bug 1122014 has been marked as a duplicate of this bug. ***

Comment 2 Ilanit Stein 2014-08-05 09:37:15 UTC
How to verify (after speaking with rgolan):

1. Max VM vcpu cores should be 16
2. Max VM vcpu sockets should be 16
3. The product of vcpu sockets*cores*threads should be equal or smaller than 160.
4. Check in engine-config the values of max vcpu cores, and max vcpu sockets.
5. Check in vdsm.log, VM xml, that following start VM, after setting, for example:
cores = 16, sockets = 8, threads = 1,
that the maximum vcpu in xml = 124 (the product of these 3 params).

Comment 5 Ilanit Stein 2014-10-22 14:10:24 UTC
Verified on vt6:

1. Max VM vcpu cores should be 16 - OK
2. Max VM vcpu sockets should be 16 - OK
3. The product of vcpu sockets*cores <=160 - OK
4. Check in engine-config the values of max vcpu cores, and max vcpu sockets.
[root@dhcp160-207 ~]# engine-config -g MaxNumOfCpuPerSocket
MaxNumOfCpuPerSocket: 16 version: 3.0
MaxNumOfCpuPerSocket: 16 version: 3.1
MaxNumOfCpuPerSocket: 16 version: 3.2
MaxNumOfCpuPerSocket: 16 version: 3.3
MaxNumOfCpuPerSocket: 16 version: 3.4
MaxNumOfCpuPerSocket: 16 version: 3.5

[root@dhcp160-207 ~]# engine-config -g MaxNumOfVmCpus
MaxNumOfVmCpus: 160 version: 3.1
MaxNumOfVmCpus: 160 version: 3.2
MaxNumOfVmCpus: 160 version: 3.3
MaxNumOfVmCpus: 160 version: 3.4
MaxNumOfVmCpus: 160 version: 3.5
MaxNumOfVmCpus: 64 version: 3.0

5. Check in vdsm.log, VM xml, that following start VM, the maximum vcpu in xml = cores * sockets * threads

Comment 7 errata-xmlrpc 2015-02-11 21:12:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0159.html


Note You need to log in before you can comment on or make changes to this bug.