From c4b723fa367c19f25984fdced07962c610c90e57 Mon Sep 17 00:00:00 2001 From: Laura Hinson Date: Thu, 9 Jul 2026 13:54:58 -0400 Subject: [PATCH] [OSDOCS-20479]: CQA: Managing HCP on OpenShift Virtualization (7 of 7) --- modules/hcp-topology-spread-constraint.adoc | 18 ++++++++++-------- modules/hcp-virt-evict-vms.adoc | 7 ++++++- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/modules/hcp-topology-spread-constraint.adoc b/modules/hcp-topology-spread-constraint.adoc index 97f2d3ba5f4a..fbc9dd86e8c6 100644 --- a/modules/hcp-topology-spread-constraint.adoc +++ b/modules/hcp-topology-spread-constraint.adoc @@ -6,9 +6,10 @@ [id="hcp-topology-spread-constraint_{context}"] = Spreading node pool VMs by using topologySpreadConstraint -By default, KubeVirt virtual machines (VMs) created by a node pool are scheduled on any available nodes that have the capacity to run the VMs. By default, the `topologySpreadConstraint` constraint is set to schedule VMs on multiple nodes. +[role="_abstract"] +To avoid distribution of virtual machines (VMs) on a single node, use the descheduler to continuously honor the `topologySpreadConstraint` constraint to spread VMs on multiple nodes. -In some scenarios, node pool VMs might run on the same node, which can cause availability issues. To avoid distribution of VMs on a single node, use the descheduler to continuously honor the `topologySpreadConstraint` constraint to spread VMs on multiple nodes. +By default, KubeVirt VMs created by a node pool are scheduled on any available nodes that have the capacity to run the VMs. The `topologySpreadConstraint` constraint is set to schedule VMs on multiple nodes. In some scenarios, node pool VMs might run on the same node, which can cause availability issues. .Prerequisites @@ -36,15 +37,16 @@ metadata: spec: mode: Automatic managementState: Managed - deschedulingIntervalSeconds: 30 # <1> + deschedulingIntervalSeconds: 30 profiles: - - SoftTopologyAndDuplicates # <2> - - KubeVirtRelieveAndMigrate # <3> + - SoftTopologyAndDuplicates + - KubeVirtRelieveAndMigrate profileCustomizations: devDeviationThresholds: AsymmetricLow devActualUtilizationProfile: PrometheusCPUCombined # ... ---- -<1> Sets the number of seconds between the descheduler running cycles. -<2> This profile evicts pods that follow the soft topology constraint: `whenUnsatisfiable: ScheduleAnyway`. -<3> This profile balances resource usage between nodes and enables the strategies, such as `RemovePodsHavingTooManyRestarts` and `LowNodeUtilization`. ++ +* `spec.deschedulingIntervalSeconds` sets the number of seconds between the descheduler running cycles. +* `spec.profiles.SoftTopologyAndDuplicates` evicts pods that follow the soft topology constraint: `whenUnsatisfiable: ScheduleAnyway`. +* `spec.profiles.KubeVirtRelieveAndMigrate` balances resource usage between nodes and enables the strategies, such as `RemovePodsHavingTooManyRestarts` and `LowNodeUtilization`. diff --git a/modules/hcp-virt-evict-vms.adoc b/modules/hcp-virt-evict-vms.adoc index 6f46b8c4cee8..a2332bc884ae 100644 --- a/modules/hcp-virt-evict-vms.adoc +++ b/modules/hcp-virt-evict-vms.adoc @@ -6,7 +6,12 @@ [id="hcp-virt-evict-vms_{context}"] = Evicting KubeVirt virtual machines -In cases where KubeVirt virtual machines (VMs) cannot be live migrated, such as when you use GPU passthrough, the VMs must be evicted at the same time as the `NodePool` resource of the hosted cluster. Otherwise, the compute nodes might be shut down without being drained from the workload. This might also happen when you are upgrading the {VirtProductName} Operator. To achieve a synchronized restart, you can set the `evictionStrategy` parameter on the `hyperconverged` resource to ensure that only VMs that are drained from workloads are rebooted. +[role="_abstract"] +In cases where KubeVirt virtual machines (VMs) cannot be live migrated, such as when you use GPU passthrough, the VMs must be evicted at the same time as the `NodePool` resource of the hosted cluster. + +Otherwise, the compute nodes might be shut down without being drained from the workload. This might also happen when you are upgrading the {VirtProductName} Operator. + +To achieve a synchronized restart, you can set the `evictionStrategy` parameter on the `hyperconverged` resource to ensure that only VMs that are drained from workloads are rebooted. .Procedure