Description of problem: First of all this is a known issue, raising this bug to track it as I cannot find any. After talking to Liran, smarter CPU pinning will be introduced with BZ1782077. But until then the user may shoot himself in the foot in a specific scenario. The main issue here is that the default setting of HP VMs that are pinned to a host is 'Existing'. The user may get in trouble without even knowing it as the VMs will be pinned to the same pCPUs without the user knowing. Keep in mind users may have High Performance VMs that may may be pinned to 1+ hosts to other reasons and have no manual CPU pinning specified. 1. Create High Performance VM, pinned to Host Virtual Machines -> New System -> Total Virtual CPUs = 4 Host -> Specific Host = Host4 Optimized For = High Performance -> OK 2. The result is: engine=# select vm_name,cpu_pinning from vm_static where vm_name like 'VM%'; vm_name | cpu_pinning ---------+----------------- VM1 | 0#1_1#2_2#3_3#4 (1 row) 3. Create a new VM the same way, on the same host, like done on [1]. engine=# select vm_name,cpu_pinning from vm_static where vm_name like 'VM%'; vm_name | cpu_pinning ---------+----------------- VM1 | 0#1_1#2_2#3_3#4 VM2 | 0#1_1#2_2#3_3#4 4. Create 2 more VMs.. engine=# select vm_name,cpu_pinning from vm_static where vm_name like 'VM%' order by vm_name; vm_name | cpu_pinning ---------+----------------- VM1 | 0#1_1#2_2#3_3#4 VM2 | 0#1_1#2_2#3_3#4 VM3 | 0#1_1#2_2#3_3#4 VM4 | 0#1_1#2_2#3_3#4 Version-Release number of selected component (if applicable): rhvm-4.4.6.6-0.10.el8ev.noarch How reproducible: Always Steps to Reproduce: As above Actual results: - User not aware VMs pinned to the same pCPU. - Potential for low performance on VMs that is actually High performance type. Expected results: - Block, Warn, keep HP VM default to 'Do not Change' or do something else until smarter pinning is available.
As discussed offline, currently we are going to block the existing policy. This means - it will dropped from the UI and blocked in the backend for API usage. Until we make the existing policy more reasonable to use, this is the best solution for now.
The scope of this one is: 1. Pin the vCPUs in a way that they are better spread across the physical CPUs on the host 2. It does not mean we do dedicated pinning, i.e., other VMs that specified with pinning string or whose vCPUs are not pinned may run on the same pCPUs as the pinned vCPUs 3. This means that the pinning should be set when running the VM (we need to know on which host the VM is going to run and what's the current pinning rules on that host)
Liran, please update the patch to point to bz 1963680
Is handled as part of bz 1782077 *** This bug has been marked as a duplicate of bug 1782077 ***