Skip to content

[OSDOCS-20479]: CQA: Managing HCP on OpenShift Virtualization (7 of 7) #115019

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lahinson wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[OSDOCS-20479]: CQA: Managing HCP on OpenShift Virtualization (7 of 7) #115019

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions modules/hcp-topology-spread-constraint.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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`.
7 changes: 6 additions & 1 deletion modules/hcp-virt-evict-vms.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down