Description of problem: For DPDK type applications, the vCPU should not be interrupted or throttled by the cgroup cpu quota limitations. By default k8s sets cpu quota limitations to positive integer values, which throttles the vCPU. To disable cpu quota for pods it is necessary to annotate the pod with cpu-quota.crio.io: "disable" And set runtimeClassName to the performance profile runtimeClassName (as described at "Disabling CPU CFS quota" section of https://docs.openshift.com/container-platform/4.12/scalability_and_performance/cnf-low-latency-tuning.html). However KubeVirt does not support setting of runtimeClassName. In a discussion with Vladik, it appears an acceptable way to allow pods to set runtimeClassName would be for a scheduling policy to be created for VMs, similarly to migration policies. Version-Release number of selected component (if applicable): 4.12 How reproducible: Always Steps to Reproduce: 1. Start KubeVirt VM with cpu-quota.crio.io: "disable" annotation and runtimeclassname set (per cnf low latency tuning document above). 2. 3. Actual results: cpu.cpu_quota_us value in the pod cgroup is not -1. Expected results: cpu.cpu_quota_us value in the pod cgroup is -1. Additional info:
*** Bug 2192636 has been marked as a duplicate of this bug. ***
As per Petr from comment5 it appears it needs update in HCO first. Simone, could you please take a look?
(In reply to Kedar Bidarkar from comment #6) > As per Petr from comment5 it appears it needs update in HCO first. > > Simone, could you please take a look? Sure, a few questions (for the sake of inline documenting the new configuration option): 1. can the the value of defaultRuntimeClass be amended as a day two operations when we have existing VMIs? 2. if so, what's the impact on existing VMIs? 3. is it going to affect live migration with the target pod getting configured with the new value for defaultRuntimeClass? 4. is 4.14 enough or should we backport this down to 4.13?
Petr, feel you could help answer Simone's questions from comment10
*** Bug 2185411 has been marked as a duplicate of this bug. ***
@stirabos , regarding your 4th question on comment #10; 4. is 4.14 enough or should we backport this down to 4.13? --> The end Partner needs this bug to be backported to 4.12 as it would be the version that they will Go Live in September. Can you please let me know if you need me to file it or you can duplicate this one for 4.12? Thanks in advance!
(In reply to Ivan from comment #16) > Can you please let me know if you need me to file it or you can duplicate > this one for 4.12? OK, thanks. We will handle the BZ and the backport process on our side.
Verified with CNV v4.14 interim build (HCO bundle: v4.14.0.rhel9-1154) tl;dr: New config option: defaultRuntimeClass is introduced and it get propagated to kubevirt and VMI Validated with the following test cases: 1. hco.spec.defaultRuntimeClass and kubevirt.spec.defaultRuntimeClass gives helpful information to understand about the new option 'defaultRuntimeClass' 2. hco.spec.defaultRuntimeClass validates for the valid input value, which is a string. Boolean or numerical values didn't work as expected. 3. When hco.spec.defaultRuntimeClass is set, the value propagates as expected to kubevirt and VMI For the value to propagate to VMI, the performance profile has to be created and then the same to be set on the hco.spec.defaultRuntimeClass 4. When hco.spec.defaultRuntimeClass is set, it affects only the newly created VM, restarted VM, migrated VM. Running VMs doesn't get affected with the new option. With the above observations, marking this bug as VERIFIED
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.14.0 Images 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:6817