Manage storage for KubeVirt VMs

KubeVirt is an extension for Kubernetes that offers the flexibility to manage traditional VM-based workloads alongside modern containerized applications within a Kubernetes framework.

Portworx provides resources that VMs can use for both their initial startup process and for retaining data even when they are not running. To utilize OpenShift features, such as live migration, these volumes must have the ReadWriteMany access mode.

Follow the instructions on this page to create a StorageClass, which you can use to create the necessary PVCs.

Prerequisites

• An OpenShift cluster that supports KubeVirt.
• OpenShift Virtualization is enabled

Create a StorageClass

To ensure PVCs are compatible with KubeVirt virtual machines, they must be configured with the ReadWriteMany access mode and use NFS version 3.0 with nolock mount option as shown below in the sharedv4_mount_options parameter. To meet these requirements, create PVCs from the StorageClass with the following parameters configured:

• sharedv4: "true"
• sharedv4_mount_options: vers=3.0,nolock

1. Create the px-kubevirt-sc.yaml file:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: portworx-rwx-kubevirt
   provisioner: pxd.portworx.com
   parameters:
     repl: "3"
     sharedv4: "true"
     sharedv4_mount_options: vers=3.0,nolock
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   Toggle me to know more about volumeBindingMode!

   The volumeBindingMode=WaitForFirstConsumer flag enables Portworx to intelligently place the volumes. For more information, see the KubeVirt page.

   Note that the PVCs used by the VMs directly should not include the annotation cdi.kubevirt.io/storage.bind.immediate.requested=true. This is because such an annotation overrides the WaitForFirstConsumer setting in the StorageClass.

2. Run the following command to apply your StorageClass:

   kubectl apply -f px-kubevirt-sc.yaml

Create a PVC

Create a PVC using one of the following mechanisms. Portworx will automatically recognize it as a KubeVirt volume and apply KubeVirt-specific logic during processing. Ensure that these PVCs are configured with the RWX access mode to facilitate the required functionalities:

• Virtualization tab in the OpenShift webconsole
• Konveyor Forklift or Migration Toolkit for Virtualization
• Containerized data importer's (CDI) DataVolume

Once PVCs are created, run the following command to verify if they have the RWX access mode:

kubectl get pvc -n <vm-namespace>

NAME                  STATUS   VOLUME             CAPACITY   ACCESS MODES   STORAGECLASS             AGE
<your-kubevirt-pvc>   Bound    pvc-xxxx-xxx-xxx   1Gi        RWX            portworx-rwx-kubevirt    15h

info

If you are creating a PVC using some other mechanism, then ensure the following:

• Add the portworx.io/app: kubevirt annotation to the PVC spec. This ensures that Portworx will apply KubeVirt-specific logic when processing the volume.
• Maintain the same HA or replication factor for all volumes associated with a VM.

Create a VM

Use the version of the OpenShift documentation that is applicable to your specific setup to create a KubeVirt VM.

Once the VMs are created, each VM will start running in a virt-launcher pod.

KubeVirt facilitates the Live Migration of VMs with Portworx ReadWriteMany volumes. However, the underlying libvirtd lacks this capability, prohibiting such live migrations. To address this, the Stork webhook controller modifies the virt-launcher pod manifest. It achieves this by inserting a special shared library through LD_PRELOAD. This library intercepts the statfs() system call made by libvirtd when accessing a Portworx volume. Here is the code of this shared library.

Once the VMs are created, Portworx ensures the following:

• The newly created VMs (even with operators such as Konveyor Forklift or Migration toolkit for Virtualization), have their volumes collocated during creation. Stork will schedule the VMs on nodes where volume replicas exist, making the VMs hyperconverged (bind mounted).
• During planned node maintenance, OpenShift will live-migrate the VMs out of that node. When OpenShift reboots the node, Portworx will perform a sharedv4 service (NFS) failover, and as part of this failover, it will live-migrate the VMs to ensure they are hyperconverged once again.
• Existing VMs may have volumes that are not collocated. A background job will identify such volumes and collocate them by moving the replicas.

Further reads

• Virtual machine live migration