Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1957551

Summary: [RFE] Dynamically pin vCPUs to physical CPUs on the host
Product: Red Hat Enterprise Virtualization Manager Reporter: Germano Veit Michel <gveitmic>
Component: ovirt-engineAssignee: Liran Rotenberg <lrotenbe>
Status: CLOSED DUPLICATE QA Contact: Polina <pagranat>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.4.6CC: ahadas, emarcus, lrotenbe, mavital, sigbjorn.lie
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-27 16:21:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1979041    
Bug Blocks: 1729464    

Description Germano Veit Michel 2021-05-06 01:53:06 UTC
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.

Comment 2 Liran Rotenberg 2021-05-19 15:43:59 UTC
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.

Comment 3 Arik 2021-05-23 13:11:39 UTC
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)

Comment 4 Arik 2021-05-23 13:15:00 UTC
Liran, please update the patch to point to bz 1963680

Comment 5 Arik 2022-03-27 16:21:10 UTC
Is handled as part of bz 1782077

*** This bug has been marked as a duplicate of bug 1782077 ***