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

Bug 1862968

Summary:	[RFE] auto-set cpu and numa to a vm for best performance
Product:	[oVirt] ovirt-engine	Reporter:	Liran Rotenberg <lrotenbe>
Component:	Backend.Core	Assignee:	Liran Rotenberg <lrotenbe>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Polina <pagranat>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.4.1.4	CC:	ahadas, bugs, dfodor, emarcus, lsvaty, mavital, michal.skrivanek, rgolan
Target Milestone:	ovirt-4.4.3	Keywords:	FutureFeature, Reopened, RFE
Target Release:	4.4.3	Flags:	pm-rhel: ovirt-4.4? mavital: testing_plan_complete- pm-rhel: planning_ack? pm-rhel: devel_ack+ pm-rhel: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-engine-4.4.3.7	Doc Type:	Enhancement
Doc Text:	This enhancement introduces a new option for automatically setting the CPU and NUMA pinning of a Virtual Machine by introducing a new configuration parameter, auto_pinning_policy. This option can be set to `existing`, using the current topology of the Virtual Machine's CPU, or it can be set to `adjust`, using the dedicated host CPU topology and changing it according to the Virtual Machine.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-11 06:41:58 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:
Bug Blocks:	1884286, 1887356

Description Liran Rotenberg 2020-08-03 10:50:29 UTC

This is mainly for the use case of OCP on RHV.

This bug will allow auto-setting of the CPU pinning and NUMA pinning to get the best performance possible for a specific VM.

By that:
- The VM should be pinned to a host.
- CPU passthourgh enabled.
- The VM will get the VCPU as the PCPU the host has.
- SAP HANA implementation of CPU and NUMA configuration will be set automatically.

Ideally, for best performance, only this VM should run on the host.

Comment 1 Michal Skrivanek 2020-08-04 06:38:05 UTC

> - The VM should be pinned to a host.
I would skip pinning. We should support migration to same hosts, scheduler already takes that into account. Manual migration mode should be ok

> - CPU passthourgh enabled.
> - The VM will get the VCPU as the PCPU the host has.

why would he VM be the same size? Wha matters is to use the same topology, but that doesn't mean you have to make the VM same size, just the same "shape". I'd say we should keep the requested number of vCPUs and validate it against the socket size. Or round it to it. Or depending on API changes, maybe just use sockets as input parameter.

> - SAP HANA implementation of CPU and NUMA configuration will be set automatically.

Comment 2 Arik 2020-08-04 10:53:47 UTC

(In reply to Michal Skrivanek from comment #1)
> why would he VM be the same size? Wha matters is to use the same topology,
> but that doesn't mean you have to make the VM same size, just the same
> "shape". I'd say we should keep the requested number of vCPUs and validate
> it against the socket size. Or round it to it. Or depending on API changes,
> maybe just use sockets as input parameter.

IIRC Kubernetes/Openshift defines taints and tolerations to prevent running workloads on control plane-nodes.
Is there a requirement to run both control plane-nodes and non-control plane-nodes on the same physical server in RHV?

Comment 3 Michal Skrivanek 2020-08-04 11:04:27 UTC

and we have affinity for that. Regardless,
1) yes, you can expect in demo environments to have more workers or control&workers on the same physical host. 
2) you can have other VMs on that host, not just OCP nodes

Comment 4 Arik 2020-08-04 12:20:57 UTC

That's my point - if we set affinity to imitate how openshift on bare metal is deployed, I don't see a reason for not taking all the CPU resources on the node.
Sure, we can enable adjustments - but if we aim for the simplest solution that "fix them all", it sounds like an overspec
But if we take into account the use-cases you've mentioned, we probably shouldn't take openshift on bare-metal as a reference

Comment 7 Polina 2020-10-28 20:43:34 UTC

verified on the base of added polarion plan. ovirt-engine-4.4.3.8-0.1.el8ev.noarch. Automation must be added (https://issues.redhat.com/browse/RHV-39430)

Comment 9 Sandro Bonazzola 2020-11-11 06:41:58 UTC

This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.3 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.

Comment 10 Eli Marcus 2020-11-22 17:59:11 UTC

Hi Liran, 
please review this doc text for the errata and release notes: 

This enhancement introduces a new option for automatically setting the CPU and NUMA pinning of a Virtual Machine by introducing a new configuration parameter, auto_pinning_policy. This option can be set to `existing`, using the current topology of the Virtual Machine's CPU, or it can be set to `adjust`, using the dedicated host CPU topology and changing it according to the Virtual Machine.

Comment 12 Liran Rotenberg 2020-11-23 07:25:55 UTC

Doc looks good. Thanks Eli!

Comment 13 meital avital 2022-08-01 11:51:06 UTC

Due to QE capacity, we are not going to cover this issue in our automation