Fedora Account System
Red Hat Associate
Red Hat Customer
+++ This bug was initially created as a clone of Bug #2115371 +++ 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: --- Additional comment from Kedar Bidarkar on 2022-08-08 14:17:27 UTC --- Moving this to 4.11.1 till we have a solution, where in we are not required to skip these tests in PSI Setups. --- Additional comment from Kedar Bidarkar on 2022-08-08 16:11:49 UTC --- 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
This is to track that the fix for this lands in the latest release as well as z stream.
Intel documentation states: 17.12.1 Invariant TSC The time stamp counter in newer processors may support an enhancement, referred to as invariant TSC. Processors support for invariant TSC is indicated by CPUID.80000007H:EDX[8]. The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states. This is the architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition or access to a platform resource. ------- Lets consider what needs to be done regarding tsc and VM migration: 1) Invariant TSC (invtsc flag) should only be exposed to a VM if the host it runs on has Invariant TSC (check /proc/cpuinfo output for "invtsc"). 2) Migration of a VM that has invariant TSC flag enabled should be performed to: -> A destination host that has invariant TSC. -> A destination host that is able to execute a guest with TSC frequency of the source host (which is either a destination host with the same frequency as the source host, or a destination host with TSC scaling available).
*** Bug 2125985 has been marked as a duplicate of this bug. ***
Verified on v4.12.0-548 Windows VM with HyperV Reenlightenment flag succesfully started on PSI. This VM is not migratable: > Message: HyperV Reenlightenment VMIs cannot migrate when TSC Frequency is not exposed on the cluster: guest timers might be inconsistent > $ virtctl migrate win19-dv > Error 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
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.0 Images security 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:0408