Description of problem: After the environment upgrading to OCP + CNV 4.12.1, the VMs with limits/requests resources specified can't start. memory: hugepages: pageSize: 1Gi resources: limits: cpu: "4" memory: 8Gi requests: cpu: "4" memory: 8Gi Logs generated from virtualmachine-controller is as follows: Error creating pod: Pod "virt-launcher-rhel8-ngu-2-5gmm4" is invalid: spec.containers[0].resources.requests: Invalid value: "5": must be less than or equal to cpu limit The overhead(1 CPU) was added to the virt-launcher pod(4+1=5). However, it was only added to the requests while not to the limits, as we're getting denied by the validating webhook: Error "spec.template.spec.domain.resources.requests.cpu or spec.template.spec.domain.resources.limits.cpu must be equal when DedicatedCPUPlacement is true " for field "spec.template.spec.domain.cpu.dedicatedCpuPlacement". Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Upgrade OCP + CNV env from version 4.11.* to 4.12.1. 2. Try to start a VM Actual results: The VM is always in 'starting' status, from the log, it's found the requests/limits CPU number mismatch after adding the overallocated cpu. Expected results: The overallocated CPU should be added to both requests and limits of the vmi pod . Additional info:
verified on v4.13.0.rhel9-1689 [akriti@fedora cnv-tests]$ oc get vmi NAME AGE PHASE IP NODENAME READY example 2m44s Running 10.129.2.79 virt-akr-413-mdxr5-worker-0-2crmn True [akriti@fedora cnv-tests]$ oc get vm example -o json | jq .spec.template.spec.domain.resources { "limits": { "cpu": "4", "memory": "8Gi" }, "requests": { "cpu": "4", "memory": "8Gi" } } VM is running successfully
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 (Moderate: OpenShift Virtualization 4.13.0 Images security, bug fix, and enhancement 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:3205
(In reply to Marcelo Tosatti from comment #5) > (In reply to sgott from comment #2) > > Targetting this to 4.13, but we will certainly need to backport it once > > fixed. > > Yes, it would be good to have backports for 4.12.z on this. > Hit this on a customers PoC, and also have the documentation: > > > https://access.redhat.com/solutions/7007632 > Marcelo, can you start this by proposing a backporting PR? Kaedar, would you file a 4.12 backport BZ?