Commits on Apr 18, 2024

1. Cluster-Wide CPU Feature Disablement in KubeVirt …

   This PR introduces a Kubevirt CR Configuration for cluster-wide CPU feature disablement.
   
   ****Why is this Feature needed?****
   
   - In the past, we encountered cases where libvirt's validation process failed with a CPU model, even though it is usable according to the Libvirt API. This typically happens when a CPU feature associated with the CPU model gets deprecated.
   Examples of such features are "mpx" and "tsx".
   Explicit disablement of these features in the domain XML prevents such validation failures.
   
   - Currently, we rely on reading Libvirt's internal data to prevent the failures mentioned in point 1. However, Libvirt strongly advises against accessing its internal data. Additionally, it prevents us from supporting some CPU models when a deprecated CPU feature is not supported on the node.
   
   - CPU vulnerabilities might appear in the future, and administrators need a way to mitigate these vulnerabilities at the cluster level quickly, even before they are fixed in the libvirt/qemu level.
   
   ****How to use this Feature:****
   To disable features across the entire cluster, a field named "cpuFeaturesToDisable" should be set in Kubevirt.spec.configuration.cpuFeaturesToDisable. For instance:
   spec:
     configuration:
       cpuFeaturesToDisable:
         Skylake-Client-noTSX-IBRS:
           - aes
           - mpx
         Opteron_G2"
           - svm
   
   This configuration will result in the disablement of aes and mpx whenever the CPU Model is Skylake-Client-noTSX-IBRS, and also result in the disablement of svm whenever the CPU Model is Opteron_G2. Note that setting this in Kubevirt.spec.configuration.cpuFeaturesToDisable won't be reflected in the VMI Spec.
   
   ****Why this solution is the preferred solution?****
   
   Before this PR, if a CPU feature needed to be disabled for a CPU model due to a bug in qemu/libvirt or due to CPU vulnerabilities, users might have had to take multiple actions:
   
   Disable the Node Labeller.
   Add CPU model labels to nodes.
   Restart VMs with the problematic CPU feature to disable it.
   Create VMs with the problematic CPU feature disabled.
   After this PR, the required actions will be reduced to:
   
   Restart VMs with the problematic CPU feature.
   Furthermore, this solution enables broader CPU model support. For example, after this PR, KubeVirt will support Skylake on nodes that lack the mpx feature (which is currently not supported).
   
   ****How does this feature affect new VMs?****
   
   Kubevirt.spec.configuration.cpuFeaturesToDisable only affects the libvirt domain XML input provided by KubeVirt, resulting in feature disablement at the QEMU level.
   
   For example, if the cpuFeaturesToDisable map contains the key and value Skylake-Client-noTSX-IBRS: "aes,mpx", the libvirt domain XML input will include the following:
   
   ...
   <cpu mode='custom' match='exact' check='full'>
     <model fallback='forbid'>Skylake-Client-noTSX-IBRS</model>
     <topology sockets='1' dies='1' cores='1' threads='1'/>
     <feature policy='disable' name='aes'/>
     <feature policy='disable' name='mpx'/>
   ...
   With this new configuration, existing guest VMs won't be affected because it only changes the domain XML, which doesn't change once the VMs are running, even during live migrations. Additionally, the VMI CRs at the Kubernetes level won't be affected in any way by the configuration.
   
   For more information, please refer to:
   https://libvirt.org/formatdomain.html#cpu-model-and-topology
   
   ****How does this feature affect running VMs?****
   With this new feature, existing VMs won't be affected because it only changes the domain XML, which doesn't change once the VMs are running, even during live migrations.
   
   ****Handling Conflicts Between cpuFeaturesToDisable and CPU Features API:****
   If Kubevirt.spec.configuration.cpuFeaturesToDisable conflicts with the CPU features specified in VMI.Spec.Domain.CPU.Features, the configuration policy specified in VMI.Spec.Domain.CPU.Features will determine the behavior.
   
   ****Impact on scheduling:****
   Kubevirt.spec.configuration.cpuFeaturesToDisable does not affect scheduling. Neither launcher affinity nor label selectors are influenced by it. Additionally, node labels remain unchanged regardless of the features included in the cpuFeaturesToDisable.
   
   ****Changes to Kubevirt.spec.configuration.cpuFeaturesToDisable:****
   After removing cpuFeaturesToDisable from KubeVirt's configuration, restarting existing VMs or creating new ones will no longer disable features in the guest VMs.
   After modifying cpuFeaturesToDisable in KubeVirt's configuration, restarting existing VMs or creating new ones will disable features in the guest VMs according to the modified configuration.
   
   In both cases, existing VMs will remain unchanged even when live migrating them to different nodes, so the disabled features will remain disabled.
   
   Signed-off-by: bmordeha <bmordeha@redhat.com>

   

   Barakmor1 committed Apr 18, 2024
   Copy the full SHA

   4575b32 View commit details

   Browse the repository at this point in the history

2. Add unit tests for cpuFeaturesToDisable configuration functionality …

   Signed-off-by: bmordeha <bmordeha@redhat.com>

   

   Barakmor1 committed Apr 18, 2024
   Copy the full SHA

   02ddef8 View commit details

   Browse the repository at this point in the history

3. Add functional test for Cluster-Wide CPU Feature Disablement …

   using cpuFeaturesToDisable configuration
   
   Signed-off-by: bmordeha <bmordeha@redhat.com>

   

   Barakmor1 committed Apr 18, 2024
   Copy the full SHA

   90a4662 View commit details

   Browse the repository at this point in the history