Rob Pankow 
Run the inventory and the encrypted machines are almost never the whole estate. They are a subset: the finance cluster, two databases under a contractual obligation, a handful of machines somebody encrypted in 2021 that nobody has looked at since. Five percent of the estate, twelve, occasionally thirty.
That subset has a different migration path from everything around it, and the difference is not the cryptography. Every serious platform can encrypt a volume. The difference is custody: who holds the key, where that holder physically lives, and what happens to it on the day the thing it lives inside is powered off for the last time.
On VMware® vSphere, both encryption features terminate in the same component, a Key Provider. And the Key Provider is the one part of the trust chain that has nowhere to land on the destination platform. It is not a construct that gets translated into a Kubernetes equivalent. It is a dependency that has to be resolved, on the source side, before the decommission date, or the encrypted subset of your estate becomes a problem at exactly the moment you have the least slack.
The two features, the two layers, and the one thing they share
Two distinct vSphere features are commonly described in the same breath as “our VMs are encrypted,” and they behave completely differently on migration day. Telling them apart is the whole of the first decision.
VM Encryption operates at the hypervisor, above the datastore. The VM’s files are encrypted: the VMDK, the .nvram firmware state, the swap file, the logs. A data encryption key encrypts the VM’s data, and that key is itself wrapped by a key encryption key that comes from the Key Provider. The guest operating system knows nothing about it. Critically, the ciphertext is the file: anything that copies the VMDK at the file level, without going through a host that holds the key, gets bytes it cannot use.
vSAN data-at-rest encryption operates below the datastore, at the device level. Data is encrypted as it is written to the cache and capacity devices, and decrypted transparently on the way back up. It is a cluster-wide setting rather than a per-VM one, and it protects against a very specific threat: a drive leaving the building, through theft, RMA or decommission. It does not follow the data anywhere. Read a VM out of a vSAN cluster over the network and what arrives on the other end is plaintext, because the decryption happened several layers below the thing doing the reading.
That asymmetry is the single most consequential fact in this post, and it is routinely missed. vSAN data-at-rest encryption is not a portability problem. It is a compliance problem. It will not block a single migration, and it will not protect a single byte once the data is in flight, but the control it represents has to exist again on the destination or you have quietly dropped a requirement your auditor is still expecting. VM Encryption is the reverse: it is a genuine portability problem, and whether it is also a compliance problem depends on what you replace it with.
What they share is the Key Provider, and this is where the two possible configurations diverge sharply.
An external KMIP server is a separate system. It is a cluster of appliances or a software service, it has its own lifecycle, and it is entirely independent of the vCenter that talks to it. It will still be standing the day after the vCenter is gone.
The vSphere Native Key Provider is not. It was introduced precisely so that teams could use VM Encryption and vTPM without procuring a KMIP estate, and it works by deriving keys inside vCenter itself, with a backup exported as a password-protected file. It is convenient, it is widely deployed for exactly that reason, and it is a trust anchor that exists only inside the vCenter you have scheduled for decommission.
So the first question is not “how do we migrate encrypted VMs.” It is “which of those two is holding our keys,” because the answer changes which paths are open to you and how much time you have.
Note the top layer as well. In-guest encryption, LUKS on a Linux guest or BitLocker on a Windows one, is the one form of encryption that travels without any work at all, because the key custody lives inside the guest and moves with it. That is a genuine advantage on migration day, with one large caveat: on a Windows guest, BitLocker is frequently sealed against a virtual TPM, which turns it back into a firmware-state problem rather than a key-provider one. That question is answered separately in what happens to vTPM and EFI firmware state after the vSphere exit, and this post does not re-open it.
Which VMs are actually encrypted, and under which provider
Before any path can be chosen, three facts have to come out of the estate, per VM. Most teams have the first, few have the second, and almost nobody has the third written down anywhere.
One: which VMs carry VM Encryption. This is a storage policy attribute rather than a property of the guest, so the inventory comes from the policy layer, not from asking application owners. Every VM associated with an encryption storage policy is in scope, and the list is usually longer than the one people carry in their heads, because encryption policies get applied to templates and then inherited by everything cloned from them.
Two: whether the cluster has vSAN data-at-rest encryption enabled. This is a single cluster-level answer, and it applies to every VM on that cluster whether or not anyone intended it. It tells you nothing about migration mechanics and everything about which compliance control you are about to stop providing.
Three: which Key Provider each encrypted VM resolves to. An estate that has been running for a few years very often has both: an older external KMIP integration for one set of clusters, and a Native Key Provider added later for a newer one, or for the vTPM requirement that came with Windows 11 guests. The migration path is different for each, so a single estate-wide answer is usually the wrong answer.
Two further facts are worth pulling in the same pass, because they change the arithmetic later. How much capacity the encrypted subset occupies, since one of the three paths needs room for a rewrite on the source side. And whether the Native Key Provider backup has ever actually been exported and stored somewhere outside vCenter, because on a great many sites the honest answer is no, and that single gap collapses the set of available paths down to one.
Not sure the encrypted subset of your estate has a landing place? If you are working out how key custody, per-volume encryption and the rest of the storage requirements land on the destination platform, it is worth an hour with someone who has done the mapping before. Talk to a storage architect
Three paths for an encrypted VM, and what each one costs
There are three defensible ways through this, and the condition that makes each one correct is mostly determined by what the inventory said. None of them is the obvious best choice in all cases, and the one that looks cheapest is usually the one with the plaintext window in it.
Table 1: The three paths for an encrypted VM, with the condition that makes each one correct
| Path | What it costs | What survives the exit | Choose it when |
|---|---|---|---|
| Decrypt in place, then migrate | A full rewrite of every encrypted VMDK on the source storage before migration starts, plus source-side headroom and a plaintext window on vSphere | Nothing. Clean break from the vSphere key chain | The Native Key Provider holds your keys, you have the source capacity and the maintenance window, and the estate is small enough to work through |
| Migrate through the hypervisor path, encrypt on landing | No source rewrite, but the data is plaintext in flight and the destination has to be ready to encrypt from day one, not later | Nothing of the chain, but no plaintext ever lands at rest | Your migration tooling reads through the vSphere data path on a host that holds the key, and the transfer network is one you are willing to treat as trusted |
| Preserve the external custodian, re-key at the destination | Running the KMIP estate past the vCenter decommission, plus integration work to make the destination talk to it | The trust anchor, the key history, and a continuous audit trail | You have an external KMIP server rather than a Native Key Provider, and compliance requires custody you can demonstrate was never broken |
Path one is the honest default when the Native Key Provider is in play, and the reason is blunt: the anchor is inside the machine you are switching off. You either resolve the dependency while vCenter is still running, or you preserve the Native Key Provider backup with the diligence of a root CA key and accept that you now have a long-lived secret with no system around it. Most teams should decrypt. The cost is real and it is usually under-estimated, because decrypting a VM is not a metadata operation. It is a rewrite of every block, it needs somewhere to put the result, and on an estate where the encrypted subset is measured in tens of terabytes it is a scheduling problem rather than an afternoon.
Path two is the one that gets chosen by accident, which is the argument for choosing it deliberately instead. Migration tooling that reads a VM through the vSphere data path, on a host that already holds the key, receives plaintext. That is not a flaw; it is how transparent encryption is supposed to work. But it means a team can migrate its entire encrypted subset without ever consciously deciding to, and end up with plaintext copies on the destination because the destination’s encryption was on the second phase of the project plan. If this is the path, the destination’s encryption has to be configured and verified before the first encrypted VM moves, not after.
Path three is the only one that preserves anything, and it is available only to the teams that invested in an external KMIP estate. Since KMIP is a protocol rather than a product, the same custodian can potentially serve the destination platform, which turns a break in the chain into a re-key. Whether that is worth the integration work depends entirely on whether anyone will ever have to prove custody was continuous. If the answer is yes, it is worth a great deal, because the alternative is an evidential gap that no amount of documentation closes retroactively.
One thing all three paths share: the encrypted subset should be sequenced separately from the rest of the estate, and usually last. It has different prerequisites, a different failure mode, and the highest probability of needing a second attempt. Folding it into the general migration waves is how it ends up being attempted for the first time in the final week. The broader sequencing question is covered in the storage decisions behind a vSphere to OpenShift migration and in the KubeVirt migration guide.
What the destination has to be able to do
Whichever path is taken, the same requirement lands on the destination, and it is worth stating as a requirement rather than as a product pitch, because it is what should go on the evaluation sheet.
Encryption has to be present at the storage layer, and it has to be one of the things you already bought. This is where a lot of exit projects meet an unwelcome surprise on the Red Hat® OpenShift® side, because storage capability is distributed across editions in a way that does not match intuition. Which capabilities are included in OpenShift Container Platform, which arrive only with OpenShift Platform Plus, and which are a separate per-two-core purchase on top is set out in what storage each OpenShift edition actually includes. Checking that before the exit is cheaper than discovering it during one.
Key custody has to sit with something the destination controls. This is the part that genuinely does translate: the destination replaces a KMIP appliance or a Native Key Provider with the key management the Kubernetes platform already runs, and that mechanism is the new trust anchor. The practical shape of that on the destination side is covered in encrypting Kubernetes persistent volumes with Vault KMS, which is the destination-side answer to the question this post asks from the source side.
The granularity has to match the obligation. vSAN data-at-rest encryption was a cluster-wide control. VM Encryption was per-VM. If the destination offers only one of those shapes, some workload is going to be either over-protected at a performance cost or under-protected at a compliance one. Per-volume control is the safer requirement to write down.
And the geography has to be describable, because the encryption question and the data residency question are usually asked by the same person in the same meeting. That leg is covered in data residency requirements for storage after a VMware exit.
On the simplyblock side, the relevant facts are short. Encryption is part of the platform rather than a separately licensed tier, alongside replication, disaster recovery, S3 backup and QoS, so the capability does not arrive as a second purchase discovered halfway through an exit. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. The storage layer presents volumes over NVMe/TCP to both VMs and containers, which means the encrypted subset of a migrated estate does not need a separate storage design from everything else, and the backing devices are not restricted to local NVMe, so capacity from an array you already own can be taken into the pool during a transition. Two caveats travel with that last point: local NVMe remains the production performance recommendation, and simplyblock formats the devices it takes in, so this reuses the capacity rather than wrapping existing LUNs in place.
The general shape of what replaces the datastore is covered in replacing the VMware datastore on Kubernetes, and the underlying concepts in the glossary entries on Kubernetes storage encryption and VMware storage migration to Kubernetes. If the question you actually have is the more general one about protecting data at rest, the encryption at rest explainer answers it directly and this post assumes it.
Questions and Answers
Can I migrate an encrypted VM to OpenShift Virtualization without decrypting it first?
Not as ciphertext you can use. A VM encrypted with VM Encryption is encrypted under a key that only the vSphere Key Provider can supply, and the destination has no way to ask for it. In practice you either decrypt on the source before moving, or you let the migration read through a vSphere host that already holds the key, which yields plaintext in flight and requires the destination’s own encryption to be live before the first machine moves. For most teams the cleanest answer is to choose a destination where encryption is part of the storage platform rather than an add-on, configure it first, and treat the migration as a re-encryption rather than a copy. Simplyblock includes encryption in the platform alongside replication and disaster recovery, which removes the licensing question from an already busy critical path.
What happens to vSAN data-at-rest encryption when I leave vSphere?
Nothing, mechanically, and that is the trap. It encrypts data on the way to the physical devices and decrypts it on the way back, so anything reading a VM over the network gets plaintext regardless. It will never block a migration. What it will do is silently disappear as a control: the protection against a drive leaving the building through RMA or decommission has to be provided again by the destination, and because it never caused a migration failure, nobody notices it is gone until an audit asks.
Does the vSphere Native Key Provider work after vCenter is decommissioned?
No, and this is the sharpest deadline in the whole exercise. The Native Key Provider derives its keys inside vCenter. Its backup file is the only thing that outlives the appliance, and it is a password-protected secret with no surviving system around it. If your encrypted VMs resolve to a Native Key Provider, the dependency has to be resolved while vCenter is still running. An external KMIP server is a different story: it is an independent system, it survives the decommission, and it can potentially serve as the custodian during the transition.
Do I need a separate licence for encryption on the destination storage layer?
That depends entirely on the destination, and it is worth checking rather than assuming. On OpenShift in particular, storage capability is split across editions and some of what buyers expect to be covered is a separate per-two-core purchase, which is set out in the editions post linked above. With simplyblock, encryption is included rather than tiered, along with replication, disaster recovery, S3 backup and QoS.
Is Ceph a reasonable destination for the encrypted subset?
It can be. Ceph supports encryption at rest and integrates with external key management, and it remains a good option when raw performance is not the main goal. The trade-offs to weigh are the operational burden of running it and the efficiency of its data placement, both of which show up as staffing and as hardware spend rather than as a missing feature. Comparisons of that kind are worth making on a specific mechanism rather than in the abstract, and on figures drawn from publicly available information rather than presented as independently verified.
