Bug 2217913 - [cnv-4.12] kubevirt should allow setting cluster-wide virt-launcher runtimeclass
Summary: [cnv-4.12] kubevirt should allow setting cluster-wide virt-launcher runtimeclass
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Installation
Version: 4.12.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.12.5
Assignee: Simone Tiraboschi
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On: 2203291 2217910
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-27 12:56 UTC by Simone Tiraboschi
Modified: 2023-09-25 16:55 UTC (History)
15 users (show)

Fixed In Version: hco-bundle-registry-container-v4.12.5-8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2217910
Environment:
Last Closed: 2023-08-01 14:51:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt hyperconverged-cluster-operator pull 2404 0 None open [release-1.8] Expose defaultRuntimeClass 2023-06-27 16:39:52 UTC
Red Hat Issue Tracker CNV-30334 0 None None None 2023-06-27 12:57:01 UTC
Red Hat Product Errata RHSA-2023:4421 0 None None None 2023-08-01 14:52:14 UTC

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
Note You need to log in before you can comment on or make changes to this bug.