Bug 2217913

Summary:	[cnv-4.12] kubevirt should allow setting cluster-wide virt-launcher runtimeclass
Product:	Container Native Virtualization (CNV)	Reporter:	Simone Tiraboschi <stirabos>
Component:	Installation	Assignee:	Simone Tiraboschi <stirabos>
Status:	CLOSED ERRATA	QA Contact:	SATHEESARAN <sasundar>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.12.0	CC:	danken, dbasunag, gveitmic, igarcia, jortialc, kbidarka, mtosatti, ngavrilo, ngu, nunnatsa, phoracek, sasundar, sgott, stirabos, vromanso
Target Milestone:	---
Target Release:	4.12.5
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	hco-bundle-registry-container-v4.12.5-8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	2217910	Environment:
Last Closed:	2023-08-01 14:51:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2203291, 2217910
Bug Blocks:

Comment 1 Dan Kenigsberg 2023-07-13 09:12:23 UTC

Fixing bug summary to reflect what's delivered.

Comment 2 SATHEESARAN 2023-07-14 07:15:06 UTC

Tested with CNV interim build with version v4.12.5-23 with the following test cases:

1. hco.spec.defaultRuntimeClass and kubevirt.spec.defaultRuntimeClass provides relevant information
about this option.

2. PerformanceProfile is created with the name 'performance-customcpu'.
When 'hco.spec.defaultRuntimeClass' is set with 'performance-customcpu', the value persisted in hco
and also propagated to kubevirt (i.e) kubevirt.spec.configuration.defaultRuntimeClass

<snip>
# oc get nodes
NAME                               STATUS   ROLES                  AGE     VERSION
c01-ss-412s-d2xh5-master-0         Ready    control-plane,master   4h26m   v1.25.11+1485cc9
c01-ss-412s-d2xh5-master-1         Ready    control-plane,master   4h26m   v1.25.11+1485cc9
c01-ss-412s-d2xh5-master-2         Ready    control-plane,master   4h26m   v1.25.11+1485cc9
c01-ss-412s-d2xh5-worker-0-lgjv2   Ready    worker                 4h8m    v1.25.11+1485cc9
c01-ss-412s-d2xh5-worker-0-ptq2m   Ready    worker                 4h11m   v1.25.11+1485cc9
c01-ss-412s-d2xh5-worker-0-xwtvd   Ready    worker                 4h10m   v1.25.11+1485cc9

# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-dec3176cbb7fdecee9267cbf97694609   True      False      False      3              3                   3                     0                      4h23m
worker   rendered-worker-0293c54fa60cde43a1acbb15eb97e274   True      False      False      3              3                   3                     0                      4h23m

# oc edit hco kubevirt-hyperconverged -n openshift-cnv
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged edited

# oc get performanceprofile
NAME        AGE
customcpu   80m

# oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq '.spec.defaultRuntimeClass'
"performance-customcpu"

# oc get kubevirt kubevirt-kubevirt-hyperconverged -n openshift-cnv -o json | jq '.spec.configuration.defaultRuntimeClass'
"performance-customcpu"
</snip>

3. 'runtimeClassName' is set on the newly created virt-launcher pod, but not on the 'running' existing VM
Created a VM, before setting hco.spec.defaultRuntimeClass. Then set the hco.spec.defaultRuntimeClass to value 'performance-customcpu',
Validated that the already running VM is not affected, where as the newly created VM got the value reflected in virt-launcher.spec.runtimeClassName

<snip>
# oc get pod
NAME                                          READY   STATUS    RESTARTS   AGE
virt-launcher-fedora-fmcab7bk6mapxr01-f27fq   1/1     Running   0          22m       <---- VM running after 'hco.spec.defaultRuntimeClass' is set
virt-launcher-fedora-rg7c7o7qathfey4p-jdg6d   1/1     Running   0          27m       <--- VM was running before 'hco.spec.defaultRuntimeClass' is set

# oc get pod virt-launcher-fedora-rg7c7o7qathfey4p-jdg6d -o json | jq '.spec.runtimeClassName'
null

# oc get pod virt-launcher-fedora-fmcab7bk6mapxr01-f27fq -o json | jq '.spec.runtimeClassName'
"performance-customcpu"
</snip>

4. Restarting the running VM refelected virt-launcher.spec.runtimeClassName corresponding to hco.spec.defaultRuntimeClass

5. When 'hco.spec.defaultRuntimeClass' is removed, it reflected in hco.spec.defaultRuntimeClass and also propagated well to kubevirt.spec.configuration.defaultRuntimeClass
<snip>
# oc edit hco kubevirt-hyperconverged -n openshift-cnv
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged edited

# oc get hco kubevirt-hyperconverged -n openshift-cnv -o json | jq '.spec.defaultRuntimeClass'
null

# oc get kubevirt kubevirt-kubevirt-hyperconverged -n openshift-cnv -o json | jq '.spec.configuration.defaultRuntimeClass'
null
</snip>

Comment 8 errata-xmlrpc 2023-08-01 14:51:33 UTC

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 (Important: OpenShift Virtualization 4.12.5 security and bug fix update), 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-2023:4421