You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context:
TSC frequencies are needed by VMs in several use-cases. In some scenarios these frequencies are required to schedule the VM, and in others they're required in order to migrate the VM.
Since all nodes support different TSC frequencies, the lowest frequency on the cluster is being found and used. That way a VM can schedule / migrate to one of the following:
Nodes that support this frequency directly
Nodes that support higher frequencies, but support tsc-scaling which means they can also support lower frequencies.
What happened:
Consider the following scenario:
A cluster is being set up in a way that master nodes are schedulable.
The admin decides to turn them to be unschedulable. In this case, virt-handler pods would still run on these nodes.
Since virt-handlers are still running on these nodes, they are considered as schedulable from Kubevirt's perspective
In the above scenario, the lowest TSC frequency can be found on an unschedulable node that still runs virt-handler. It's possible that no other nodes support this TSC frequency. In such a scenario, VMs that depend on TSC frequency wouldn't be able to schedule/migrate.
What you expected to happen:
The chosen lowest TSC frequency should be supported on at least one node that VMs can schedule/migrate to.
How to reproduce it (as minimally and precisely as possible):
Create a cluster with master unschedulable nodes
On these nodes, disable node-labeller. Then, override TSC labels to mock supporting a very low frequency (it needs to be the lowest frequency supported in the cluster).
Context:
TSC frequencies are needed by VMs in several use-cases. In some scenarios these frequencies are required to schedule the VM, and in others they're required in order to migrate the VM.
Since all nodes support different TSC frequencies, the lowest frequency on the cluster is being found and used. That way a VM can schedule / migrate to one of the following:
tsc-scaling
which means they can also support lower frequencies.What happened:
Consider the following scenario:
In the above scenario, the lowest TSC frequency can be found on an unschedulable node that still runs virt-handler. It's possible that no other nodes support this TSC frequency. In such a scenario, VMs that depend on TSC frequency wouldn't be able to schedule/migrate.
What you expected to happen:
The chosen lowest TSC frequency should be supported on at least one node that VMs can schedule/migrate to.
How to reproduce it (as minimally and precisely as possible):
invtsc
CPU featureMore Info:
for more info, please look at #10169 and specifically #10169 (comment).
Environment:
virtctl version
):Client Version: version.Info{GitVersion:"v0.37.0-rc.0.8689+1c845a9d5d793b-dirty", GitCommit:"1c845a9d5d793bd363c27e16c0e7b329cb85e30f", GitTreeState:"dirty", BuildDate:"2023-07-26T14:16:25Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{GitVersion:"v0.37.0-rc.0.8522+e25174f3d21ad9", GitCommit:"e25174f3d21ad9202d534cba14bcd4eeb36ca9d6", GitTreeState:"clean", BuildDate:"2023-07-25T13:09:11Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"linux/amd64"}
kubectl version
):Client Version: v1.27.3
CentOS Stream 9
uname -a
):Linux node01 5.14.0-331.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 22 15:26:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: