Description of problem: Unable to start Windows VMs on PSI setups. Version-Release number of selected component (if applicable): 4.11.0-587 How reproducible: On PSI Setups. Steps to Reproduce: 1. Create any windows VMs on PSI Setups 2. 3. Actual results: Windows VMs on PSI Setups, fail to start with the below message. {"component":"virt-controller","level":"info","msg":"reenqueuing VirtualMachineInstance default/vm-win10-411new","pos":"vmi.go:272","reason":"failed to determine the lowest tsc frequency on the cluster: no schedulable node exposes a tsc-frequency","timestamp":"2022-08-04T11:48:10.942248Z"} As we don't see any tsc frequency label on worker nodes of PSI Clusters. Expected results: Windows VMs on PSI Setups work fine. Additional info:
Moving this to 4.11.1 till we have a solution, where in we are not required to skip these tests in PSI Setups.
This issue is seen because the tsc labels are not present on the PSI Clusters ( Virtual Machine based worker nodes) Worker Nodes. cpu-timer.node.kubevirt.io/tsc-frequency=2095077000 cpu-timer.node.kubevirt.io/tsc-scalable=true
I verified it on v4.11.1-20 - Windows succesfully started on PSI: > $ oc get vm > NAME AGE STATUS READY > win-10-1664569276-268539 16m Running True > > $ oc get pod > NAME READY STATUS RESTARTS AGE > virt-launcher-win-10-1664569276-268539-kr7ht 1/1 Running 0 18m But it is not migratable: > $ virtctl migrate win-10-1664569276-268539 >Er ror migrating VirtualMachine Internal error occurred: admission webhook "migration-create-validator.kubevirt.io" denied the request: Cannot migrate VMI, Reason: NoTSCFrequencyNotLiveMigratable, Message: HyperV Reenlightenment VMIs cannot migrate when TSC Frequency is not exposed on the cluster: guest timers might be inconsistent If I understand correctly - it is expected that this VM is not migratable, but in our automation we have several tests with migrating Windows VM, so we still can't run some tests on PSI cluster without workaround (removing hyperv.reenlightenment from the VM spec)
*** Bug 2100629 has been marked as a duplicate of this bug. ***
Moving to Verified since it is expected behavior
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.11.1 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-2022:8750