Bug 1954920

The problem here is that there is a use of Adjust policy and the host has pretty bad hardware to use this feature with.
If you have too many pCPU, you might not get a CPU pinning at all (if vCPUs / host sockets / host threads == 0) and 1 thread is optional but isn't entirely suitable to this feature as well.

When using adjust the VM topology is adjusted to the host hardware.
It will set the CPUs like this:
vSockets = pSockets
vCores = pCores - 1
vThreads = pThreads

Our problem is that this host had 1 core. We should not allow to set 0 as cores. It is also might be an indicator for the host not really fitting the feature.
In such case we need to do one of these:
1. Nothing, and just return like you didn't set adjust policy.
2. Do vCores = pCores without dropping one.
3. Look for optional -1 in sockets/threads.

Note that the 1 core decrease is to let the host enough breathing space.

Right, but still - we shouldn't fail to run the VM in this case
It's better to fail AddVm/UpdateVm than getting into a situation we have a VM that cannot run due to invalid configuration

(In reply to Arik from comment #2)
> Right, but still - we shouldn't fail to run the VM in this case
> It's better to fail AddVm/UpdateVm than getting into a situation we have a
> VM that cannot run due to invalid configuration

Yes, checking for 1 core combined with adjust in the validation phase is also a good solution.

why did we choose blocking it instead of keeping the pinning to host cores(i.e there would be no additional "space", sure, but at least you do not add a failure that someone needs to deal with, understand, etc)

Michal, it's not that simple - in order to support auto-adjusting with such hardware we'll need to change the logic of the auto-adjust to produce valid configuration
not that it's so complicated, but it's just redundant - better to just block it for hardware that it doesn't fit for

blocking anything is also a major source of frustration. We do that when we have no choice and there is a risk of wrong behavior.

yes, for the most part
but we also block things that we don't test or that doesn't really make sense - like high-availability for vms that are pinned to a single host ;)

The only good use case for this is a big VM on a big 1 NUMA host that requires high performance. So the user can click a button instead of manually typing that not user friendly at all pinning string in the resource allocation tab.

I think we're talking about two different things - (A) a single numa node; (B) a single core per socket
IIUC, the auto-pinning assignment failed with a single core per socket and should work well with a single NUMA host where core-per-socket > 1
Liran, please keep me honest

(In reply to Arik from comment #9)
> I think we're talking about two different things - (A) a single numa node;
> (B) a single core per socket
> IIUC, the auto-pinning assignment failed with a single core per socket and
> should work well with a single NUMA host where core-per-socket > 1
> Liran, please keep me honest

Correct.

In that case I'd agree blocking is a fine resolution for this.

verified on ovirt-engine-4.4.7-0.23.el8ev.noarch.

found a host with 1 core.
host lscpu: 

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           4
NUMA node(s):        1
Vendor ID:           GenuineIntel
BIOS Vendor ID:      Red Hat
CPU family:          6
Model:               85
Model name:          Intel Xeon Processor (Skylake)
BIOS Model name:     RHEL 7.5.0 PC (i440FX + PIIX, 1996)
Stepping:            4
CPU MHz:             2294.606
BogoMIPS:            4589.21
Virtualization:      VT-x
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
L3 cache:            16384K
NUMA node0 CPU(s):   0-3

In UI - Error while executing action:
golden_env_mixed_virtio_1_0:
Cannot edit VM. The Auto Pinning policy Adjust cannot be applied to a VM that is pinned to a single core host.

In Rest API - 
2021-06-02 16:11:48,108+03 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-8) [] Operation Failed: [Cannot add VM. The Auto Pinning policy Adjust cannot be applied to a VM that is pinned to a single core host.]

This bugzilla is included in oVirt 4.4.7 release, published on July 6th 2021.

Since the problem described in this bug report should be resolved in oVirt 4.4.7 release, it has been closed with a resolution of CURRENT RELEASE.

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