Configure and Manage KubeVirt VM Hyperconvergence
Portworx Enterprise supports hyperconverged storage placement for KubeVirt virtual machines (VMs) on Kube Datastore (KDS). Hyperconvergence keeps a VM and its storage on the same Kubernetes node, reducing network traffic and improving I/O performance.
This topic explains how Portworx achieves hyperconvergence during VM provisioning, and restores hyperconvergence after storage placement changes.
A VM is hyperconverged when it runs on the same node as the storage pools that contain its disks. In this configuration, VM I/O remains local to the node instead of crossing the network.
Hyperconvergence is a best-effort operation. Portworx and Stork attempt to place VMs on the same nodes as their storage pools, including after pool failover and rebalance. However, hyperconvergence is not guaranteed because of node resource limitations, workload placement constraints, or VM migrations initiated by other components, such as the OpenShift Descheduler.
Portworx supports two types of hyperconvergence:
| Type | When it occurs | How it works |
|---|---|---|
| Initial hyperconvergence | When VM volumes are provisioned | Portworx places the volumes on the node where the VM is scheduled. |
| Eventual hyperconvergence | After pool placement changes | Portworx moves related pools together and requests that Stork live migrate the VM to the node hosting its storage. |
Initial hyperconvergence avoids the need for VM live migration after provisioning. Eventual hyperconvergence restores VM and storage alignment after placement changes, such as node failures or upgrades.
Initial hyperconvergence
Configure initial hyperconvergence
To place VM volumes on the node where the VM is scheduled, use a StorageClass with the following setting:
volumeBindingMode: WaitForFirstConsumer
With WaitForFirstConsumer (WFFC), Kubernetes delays volume provisioning until the VM pod is scheduled. Portworx uses this node as a placement hint.
Portworx by Everpure recommends WFFC for KubeVirt VM StorageClasses on Kube Datastore. The KDS-aware StorageClasses generated by the Portworx Operator already use WFFC. For more information, see Kube Datastore-aware StorageClasses.
During VM provisioning, Stork and Portworx work together to place the VM and its storage:
- Stork schedules the VM pod. It evaluates nodes based on CPU, memory, and volume replica availability.
- Portworx provisions the VM volumes. It uses the selected node as a placement hint and prefers storage pools on that node if sufficient capacity is available.
During VM deployment, Portworx attempts to place cloned PVCs, such as those created from golden images, and data disks on the same storage pool. To achieve colocation, Portworx temporarily increases the replica count through a high-availability (HA) update and reduces it after placement completes. Pool failover is temporarily blocked while these HA operations are in progress.
Eventual hyperconvergence
After pool placement changes, a VM might no longer run on the node that hosts its storage. This can happen after node failures or maintenance operations.
After the maintenance operation is complete, Portworx rebalances the pool. After rebalance is complete, it creates a SchedulingOptimization custom resource to request that Stork live migrate the VM to the node hosting its storage.
To view current and recent optimization requests, run:
kubectl get schedulingoptimization
Each request progresses through optimization stages until it reaches Final.
The final status can be:
SuccessfulPartialSuccessFailed
The request also records the number of VM migrations that succeeded, failed, or were skipped.
If a VM cannot be live migrated, for example because no suitable destination node is available, Portworx skips it rather than retrying indefinitely.
Trigger VM hyperconvergence manually
If VMs remain non-hyperconverged after pool failover or rebalance, you can trigger hyperconvergence manually without waiting for automatic hyperconvergence.
Run the following command:
pxctl service pool affinity-group plan --hyperconverge-only
This command creates a SchedulingOptimization custom resource. Portworx evaluates the VMs in the cluster and requests that Stork live migrate eligible VMs to the nodes hosting their storage.
The --hyperconverge-only option does not change affinity group labels. For more information, see Generate and apply a placement plan.
To monitor the request, run:
kubectl get schedulingoptimization
The request reports the same final statuses as an automatic hyperconvergence request.
Manual hyperconvergence is a best-effort operation. Portworx skips VMs that Stork cannot live migrate.