Red Hat Bugzilla – Bug 1458754
[RFE] It is not possible to add sockets to RHEV host via Satellite
Last modified: 2018-10-16 11:28:58 EDT
Description of problem: When creating or modifying the hosts within RHEV it throw the following error: RHEV: 2017-06-02 10:44:39,413+02 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-8) [] Operation Failed: [Cannot add VM. Maximum number of cpu per socket exceeded] Satellite: 2017-06-02 10:44:39 b86ea2db [app] [I] Failed to save: Failed to create a compute sbr-virt-rhv-nested (RHEV) instance ktruf-maxcpu.sysmgmt.lan: Cannot add VM. Maximum number of cpu per socket exceeded Version-Release number of selected component (if applicable): 6.2.9 Satellite RHEV 3.6, 4.0, 4.1 How reproducible: All the time Steps to Reproduce: 1. Create hosts within Satellite WebUI at RHEV with more then 16 CPUs 2. Get error Actual results: VM is not created Expected results: Vm is created successfully as per RHEV documentation with up to 240 cores for RHEV 3.6 and 4.0 and 288 for RHEV 4.1 Additional info: The limits for RHEV is the following: MaxSocket = 16 MaxNumOfCpuPerSocket = 16 MaxNumOfThreadsPerCpu = 8 Despite the fact that number of cores are limited to 16 it is possible to split it over the virtual sockets so it would have number_of_sockers*number_of_cpus cores. The correct parameters could be passed to RHEV via API. Example: <vm> <name>testvm2</name> <cpu> <topology cores="2" sockets="9"/> </cpu> <cluster> <name>Default</name> </cluster> <memory_policy> <guaranteed>1024</guaranteed> </memory_policy> <template> <name>Blank</name> </template> </vm> In this example number or cores would be 18.
Connecting redmine issue http://projects.theforeman.org/issues/10395 from this bug
Reproducer: 1) Create a RHEV computing resource (infrastructure -> computing resources) 2) Create a new host from WebUI (hosts -> new host), using that computing resource in the "Deploy on" field Result: "Failed to create a compute RHEV test (RHEV) instance testrhevhost.testdomain: Cannot add VM. Max number of cpu per socket exceeded"
FailedQA with Sat6.3 snap 18 and both RHEV 3.5.7-0.1 and RHEV 4.1.7.2-0.1. When trying to create a host with 24 CPUs, the following error occurs and the host isn't created: "Unable to save Failed to create a compute RHEV test (RHEV) instance testhost.testdomain: Cannot add VM. Max number of cpu per socket exceeded" Creating the host manually in RHEV works so this shouldn't be caused by some limit set on that RHEV instance. There is one host with 2 sockets, 6 cores per socket and 2 threads per core, which is enough for a 6:2:2 config; but even if it wasn't, it should be at least possible to create a host and not run it. Note: When creating a guest in RHEV manually, it is not enough to set 24 cores: one must specifically set the setup of 6:2:2. This might be where things go wrong.
Current supported topology maximum is 16 sockets, 16 cores/socket
Lukáš, When you tested this, did you use the same user for RHV for the compute resource login as you did to login to the RHV WebUI and create the custom host?
Yes
Created redmine issue http://projects.theforeman.org/issues/22117 from this bug
Choosing the number of cores was fixed by http://projects.theforeman.org/issues/10395 but Satellite does not have an option to choose number of sockets. I'm changing this to a RFE to add the number of sockets.
I cleaned up the sat-6.3.0? flag. It was set to backlog on 3 January.
Upstream bug assigned to oprazak@redhat.com
This was already in foreman 1.18.0, looks like automation missed it somehow. Moving to ONQA
Verified with Sat 6.4 snap 20. Used reproducer from comment 4 with 8 cores and 3 sockets. Tested with both APIv3 and APIv4. The VM got created with 24 cores as 3:8:1. I think "Cores" should actually be worded as "Cores per socket". I will verify this BZ as it's much better now than it was and create a different BZ about this nitpick issue.
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://access.redhat.com/errata/RHSA-2018:2927