Skip to main content
Version: 25.6

Run KubeVirt virtual machines with virtual TPM devices using FlashArray file services

PX-CSI supports the use of KubeVirt virtual machines (VMs) with virtual Trusted Platform Module (vTPM) devices. A vTPM provides a software-based emulation of a physical TPM, enabling features such as secure key storage, measured boot, and OS-level encryption. For more information, see Using virtual Trusted Platform Module devices.

To persist vTPM state and support operations such as live migration and failover, the vTPM device must be backed by a ReadWriteMany (RWX) file services volume. For data intensive applications, we recommend using FlashArray Direct Access shared raw block (RWX) volumes. This page explains how to configure vTPM-enabled VMs using FlashArray file services volumes provisioned through the PX-CSI driver.

note
  • You can run Windows virtual machines in Red Hat OpenShift with persistent vTPM using PX-CSI. This enables secure key storage and supports operations such as live migration and failover. For more information, see Running Windows 11 and 2022 Server Virtual Machines in Red Hat OpenShift with persistent vTPM.
  • Starting with OpenShift version 4.18, vTPM also supports ReadWriteOnce (RWO) file system. Use an RWO volume if you don't require live migration, since that feature requires RWX access to attach the volume to multiple nodes simultaneously.

Prerequisites​

Before configuring vTPM support with FlashArray file services, ensure the following:

Use RWX file system for vTPM persistent volume​

When KubeVirt automatically provisions a persistent volume for the virtual Trusted Platform Module (vTPM), it uses the vmStateStorageClass defined in the HyperConverged custom resource. To ensure that the vTPM backing PVC uses a ReadWriteMany (RWX) file system, follow these steps:

  1. Run the following command to identify the storage class used for vTPM backing volumes:

    kubectl get HyperConverged kubevirt-hyperconverged -n openshift-cnv -o yaml | grep -i vmStateStorageClass
    vmStateStorageClass: fa-file-sc

    In this example, the fa-file-sc storage class is used. For more information about creating FlashArray file services StorageClass, see Create and use FlashArray PVCs.

  2. Inspect the StorageProfile for the storage class.

    When KubeVirt or CDI creates a PVC (such as for vTPM), and no explicit accessMode or volumeMode is specified in the virtual machine spec, the platform uses the first matching entry from the claimPropertySets list in the StorageProfile.

    This behavior means:

    • The first match matters — entries at the top are preferred.
    • If RWX and Filesystem are not prioritized, the PVC may not be usable for live migration.

    To ensure correct prioritization, verify the claim property set using:

    kubectl get storageprofile fa-file-sc -o yaml
    spec: {}
    status:
    claimPropertySets:
    - accessModes:
        - ReadWriteMany
        volumeMode: Block
    - accessModes:
        - ReadWriteMany
        volumeMode: Filesystem
    - accessModes:
        - ReadWriteOnce
        volumeMode: Block
    - accessModes:
        - ReadWriteOnce
        volumeMode: Filesystem

Limitations with FlashArray file services​

The following operations are not currently supported when using FlashArray file services with KubeVirt virtual machines:

  • Cloning volumes
  • Taking snapshots
  • Performing backups
  • Deletion of non-empty volumes