Rob Pankow 
The first Windows guest through a cutover rarely fails loudly. It fails at a recovery screen, asking for a 48 digit BitLocker key that nobody in the room has, because the operating system booted, looked for the TPM that sealed its volume key, and found a different one. The disks copied perfectly. Every block arrived. The thing that did not arrive was a few kilobytes of firmware state that no migration checklist had a line for, because on the platform being left behind it had never been a separate object at all.
That state has a name on both sides of the move. On vSphere it is the .nvram file. On Kubernetes it is a PersistentVolumeClaim. The interesting part is what happens in between, and it is not a translation exercise. It is a question about what a very small volume has to guarantee.
What the vTPM actually was on vSphere
A Trusted Platform Module is a place to keep secrets that the operating system can use but cannot extract. Windows 11 requires one. Windows Server 2022 and later expect one for the features built on it. BitLocker uses it to seal the volume master key to a measured boot state, which is why an unexpected firmware change sends a machine to a recovery prompt: the seal no longer matches the measurement.
A virtual TPM is that device implemented in software, and the implementation detail that matters here is where it keeps its contents. On vSphere, a vTPM stores its data in the virtual machine’s .nvram file, and that file is encrypted using VMware® virtual machine encryption. Which means a vTPM is not an independent feature you switch on. It has a hard dependency: the cluster must have a key provider configured, either the built in vSphere Native Key Provider available from 7.0 Update 2 onward, or an external key server. No key provider, no vTPM.
Two consequences of that design travel badly, and both are worth stating before anyone plans a migration around them.
The first is that the state is encrypted under keys that belong to the source platform. A backup of a vTPM enabled VM has to include the .nvram file, and a restore only works if the encryption keys are still available. That is a supported path within vSphere. It is not a path that leads anywhere else.
The second is more fundamental and has nothing to do with VMware® at all. A TPM’s Endorsement Key is designed to be non migratable. It cannot be moved to another TPM and it cannot be changed, because the entire security value of the device rests on that property. This is why vSphere 8 offers, when cloning a VM that has a vTPM, the option to give the clone a new and blank vTPM with its own secrets and identity. Not a copy. A new one.
So the honest summary of the source side is this: the firmware state is a real object, it is encrypted, it is backed up with the VM, and it is deliberately built so that it cannot be lifted out and put down somewhere else.
Where that state lands on KubeVirt
On the destination the same problem gets solved with the primitive Kubernetes already has, which is a volume.
KubeVirt calls it backend storage, or the persistent state volume. When a virtual machine needs to keep state that lives outside the guest’s own disks, KubeVirt provisions a PVC for it automatically and labels it persistent-state-for with the name of the VM instance it belongs to. Two kinds of data go in it: TPM contents, and EFI firmware settings such as UEFI variables and custom secure boot certificates. It is the direct functional heir of the .nvram file, and unlike the .nvram file it is a first class object in the platform’s own API, which you can see, list, snapshot and lose.
Turning it on is explicit rather than automatic. The VMPersistentState feature gate has to be enabled by a cluster administrator. After that, persistence is requested per device in the VM spec: spec.domain.devices.tpm.persistent for the TPM, and spec.domain.firmware.bootloader.efi.persistent for UEFI state. Enabling TPM persistence also changes the emulated device model that the guest sees, from tpm-tis to tpm-crb. Worth knowing, because it is a visible hardware change inside a Windows guest that is already sensitive to hardware changes.
Then comes the part that belongs to the storage team rather than the virtualization team. The PVC has to come from somewhere, and KubeVirt does not guess well. The storage class is named in the KubeVirt custom resource as vmStateStorageClass, which on Red Hat® OpenShift® Virtualization is set through the HyperConverged custom resource rather than edited directly. If it is unset, the cluster default storage class is used, which is how a firmware state volume ends up on whatever happened to be marked default eighteen months ago.
That storage class carries two requirements, and they are not suggestions:
- Volume mode must be
Filesystem. Block mode does not satisfy it. - Access mode must be
ReadWriteManyif the VM is ever to live migrate. With RWO the volume cannot be held by source and target pods across the handover, so a VM with a persistent vTPM on an RWO volume is a VM that cannot be evacuated from a node.
Read that second requirement next to a normal estate and the awkwardness becomes obvious. The rest of the VM is block storage, because that is what virtual disks want and it is where the performance is. The firmware state, a volume measuring in the low megabytes, needs a shared filesystem. One small object with completely different requirements from everything around it, and it is the one that decides whether a host can be drained for patching.
The smallest volume in the estate is the one that decides whether a Windows VM can be live migrated. If your OpenShift Virtualization design has not named which storage class provisions VM state, that is worth an hour with somebody who has sized this before cutover rather than after. Talk to a storage architect
The four places firmware state breaks
Firmware state fails in a small number of specific ways, and each one has a different owner. The table below is the one to take into a migration review, because three of the four rows are storage decisions and the fourth is not fixable by anyone.
| Stage | What the state does here | How it fails | What it costs you |
|---|---|---|---|
| Migration cutover | Source secrets stay in the encrypted .nvram and do not travel | Guest boots against a new, empty vTPM | BitLocker recovery prompt on first boot. Unrecoverable without the escrowed key |
| Steady state | State PVC is bound and written on firmware or TPM changes | Volume lost, deleted with the namespace, or never backed up | Sealed keys gone. The guest may not boot, and re-enrolment is manual |
| Live migration and node drain | Both source and target need the state volume during handover | Storage class is RWO, or volume mode is Block | VM is pinned to its node. Patching means downtime |
| Snapshot and restore | State volume must be captured with the VM’s disks at one point in time | Disks and state snapshotted independently | Restored guest boots with mismatched firmware state, which behaves like a hardware swap |
The first row is the one that deserves a plain answer, because it is the row where the honest position is unfavourable to every storage vendor including this one. The vTPM’s secrets do not migrate. The Endorsement Key is non migratable by design, the state is encrypted under the source platform’s key provider, and no amount of block level fidelity in the copy changes either fact. What arrives on the destination is a new vTPM.
That makes two things migration prerequisites rather than good practice. BitLocker has to be suspended before the move, or the recovery keys have to be escrowed somewhere the team can reach them under pressure, ideally both. And any other TPM sealed secret in the guest, which in practice means Credential Guard, some certificate stores and a handful of application specific protections, has to be inventoried and re-enrolled after the move.
It is also worth knowing that the migration tooling has opinions here. Red Hat’s Migration Toolkit for Virtualization added a TPM.enabled field in 2.9.0 that can be set to false to disable the vTPM when migrating VMware VMs with UEFI settings, overriding the default preference applied to the migrated VM. An earlier version had the opposite problem, configuring a TPM on migrated Windows Server 2022 machines that never had one, fixed in 2.7.10. Check which version your migration is running on and what it will do to the device, because the default is not always the thing you want and the symptom shows up inside the guest rather than in the migration report.
The remaining three rows are yours to design. They reduce to a single question: is the storage class that provisions VM state durable, snapshot consistent with the VM’s disks, and shared enough to survive a live migration.
What the storage layer has to provide
For a volume this small, performance is irrelevant. Nobody has ever had a firmware state volume as their bottleneck. Everything that matters about it is availability, consistency and whether it is even present when you need it.
Three properties do the work.
Shared access without a separate storage system. The RWX requirement is the one that tends to generate an architecture. The common answer on OpenShift® is to run a filesystem alongside the block storage, which usually means CephFS through OpenShift Data Foundation, and Ceph is a reasonable choice when performance is not the main goal. The cost is not licensing so much as surface area: a second data path, a second failure domain and a second thing to upgrade, to serve a volume measured in megabytes. Simplyblock supports RWX directly, with pNFS parallel access rather than funnelling shared reads and writes through a single server, which means the state volume comes from the same pool as the VM disks instead of requiring a filesystem stack next to it.
Snapshots that capture the VM as one object. The fourth row of the table is a consistency problem, not a durability problem. If the disks are snapshotted at one moment and the state volume at another, a restore produces a guest whose firmware does not match its disks, and Windows reads that the way it reads any unexpected hardware change. Snapshot capability belongs to the storage layer and is included in simplyblock rather than being a separately purchased tier, which matters mainly because it removes the temptation to protect the big volumes properly and the small one casually.
Presence in the backup. The vSphere rule was that a backup had to include the .nvram file or the restore was not a restore. The Kubernetes rule is the same sentence with a different noun: a backup that captures the VM’s disks but not its persistent-state-for PVC is a backup that restores a machine which cannot unlock itself. Simplyblock ships backup to S3 compatible object storage as part of the platform, alongside replication, encryption and QoS, so the state volume is covered by the same policy as everything else rather than depending on somebody having added it to a list.
None of this is exotic. The reason it is worth writing down is that a firmware state volume is small, automatically created, and named after a label rather than after an application, which is a precise description of the kind of object that gets missed. The storage layer’s job is to make it uninteresting: same pool, same snapshot, same backup policy, same fabric, whether the estate is running hyperconverged or with storage and compute separated over NVMe/TCP.
The migration question is the one to close first, though, and it closes with an inventory rather than a product. Before cutover, find every guest with a vTPM, find every secret sealed to it, and decide where the recovery keys live. The storage design for the state volume can follow. The re-enrolment cannot be done afterwards by anyone, including the storage vendor.
Questions and Answers
Does the vTPM state migrate from vSphere to OpenShift Virtualization?
No, and this is the single most important thing to plan around. A TPM’s Endorsement Key is non migratable by design, and on vSphere the vTPM’s contents live in a .nvram file encrypted under the cluster’s key provider. The destination gets a new, blank vTPM with its own identity and secrets. Practically, that means you must suspend BitLocker or escrow its recovery keys before the move, and re-enrol anything else sealed to the TPM afterwards, such as Credential Guard. No storage layer changes this, and any vendor that implies otherwise is describing something else. Simplyblock’s role begins after the new vTPM exists, in making the volume that holds it durable and available.
Which PVC holds the firmware state on KubeVirt, and how do I find it?
KubeVirt provisions it automatically as backend storage, also called the persistent state volume, once the VMPersistentState feature gate is enabled and the VM requests persistence with spec.domain.devices.tpm.persistent or spec.domain.firmware.bootloader.efi.persistent. You can find it by the persistent-state-for label, which carries the name of the VM instance it belongs to. It holds TPM contents and EFI firmware settings, including UEFI variables and custom secure boot certificates.
What are the storage class requirements for VM state volumes?
Two hard ones. Volume mode must be Filesystem, and access mode should be ReadWriteMany if the VM needs to live migrate, because source and target both need the volume during handover. The class is selected with vmStateStorageClass on the KubeVirt custom resource, set through the HyperConverged resource on Red Hat® OpenShift® Virtualization. If you leave it unset the cluster default is used, which is how firmware state ends up somewhere nobody chose. Simplyblock serves RWX with pNFS parallel access from the same pool as the VM disks, so the state volume does not require a separate filesystem stack beside the block storage.
Do I need a separate filesystem, such as CephFS, just for vTPM state?
That is the usual answer on OpenShift and it works. Ceph is a good option when performance is not the main goal, and for a volume of a few megabytes performance genuinely is not the point. What you are paying is architectural: a second data path, a second failure domain and a second upgrade cycle to serve one small object per VM. If your storage layer already provides RWX alongside block volumes, the state PVC comes from the same pool and the same snapshot and backup policy as everything else, which is the outcome worth designing for.
What happens to a Windows guest if the state volume is lost?
It behaves as though the TPM was physically removed. Anything sealed to it stops being unsealable, so BitLocker protected volumes ask for a recovery key and TPM backed credentials have to be re-enrolled. The guest may not boot unattended. This is why the state PVC needs to be inside the same backup and snapshot policy as the VM’s disks rather than treated as scratch, and why snapshot consistency across both matters: restoring disks from one point in time and firmware state from another produces a guest whose measurements no longer match.
Is this a problem for Linux VMs too, or only Windows?
The BitLocker consequences are Windows specific, but the EFI half is not. Any UEFI guest that relies on persisted firmware variables, custom secure boot certificates or a specific boot entry order has state outside its disks, and spec.domain.firmware.bootloader.efi.persistent is what keeps it. The volume, the storage class rules and the backup requirement are identical. Windows simply fails more visibly, and sooner.
