Hyper-V Live Migration with Encrypted VHDX: Key Provisioning Limitation on Destination Hosts

Short answer

The premise needs correcting before the three questions can be answered usefully: Hyper-V on Windows Server 2022 has no native VHDX encryption mode that stores a per-host key in a DPAPI vault, and Live Migration does not depend on such a key being present on the destination host. The correct provisioning answer depends entirely on which encryption layer is actually protecting the VHDX — guest-side BitLocker, a shielded VM, or BitLocker on the Cluster Shared Volume. Each behaves differently, and none requires manual DPAPI blob export/import.

Separating the likely explanation from confirmed facts

The scenario as described — Hyper-V encrypting a VHDX with a DPAPI key that must exist on the destination — does not match documented Hyper-V behavior. What is well established:

• BitLocker inside the guest OS: the key lives in the guest (typically sealed to its virtual TPM). Hosts never hold it, so Live Migration needs no host-side key provisioning at all. This is the most common configuration and the likely source of the confusion.
• Shielded VMs: the disk encryption key is wrapped by a Key Protector that only the Host Guardian Service (HGS) can release, and only to attested, authorized guarded hosts. The "pre-provisioning" requirement is real here, but it is HGS attestation — not a DPAPI vault.
• BitLocker on the CSV (volume-level): protectors are cluster-managed, so the cluster unlocks the volume on whichever node owns the disk resource.

Answers to the three questions

1. Supported pre-provisioning method

For shielded VMs, the supported method is to enroll the destination host in the same guarded fabric: configure it as a guarded host pointing at the same HGS (or a trusted HGS) and ensure it passes attestation. HGS then releases the Key Protector to that host on demand — there is no manual export/import step. Verify with:

Get-HgsClientConfiguration
Get-VMKeyProtector -VMName <vm>

Confirm the destination shows healthy attestation against the same HGS before migrating. For guest-side BitLocker or CSV BitLocker, no pre-provisioning exists because none is needed.

2. Cluster-level or PowerShell key distribution

HGS is the native key-distribution mechanism for shielded VMs — that is its design purpose. For CSV BitLocker, the cluster itself manages protectors (check with Get-BitLockerVolume on a cluster node). There is no separate PowerShell cmdlet that pushes encryption keys between hosts, because the architecture deliberately avoids hosts holding portable keys.

3. Documented fallback for zero downtime

If the encryption genuinely comes from a third-party or custom VHDX tool using per-machine DPAPI keys, then no native Hyper-V or cluster feature synchronizes those keys — the vendor's key-management tooling is the only path, and zero-downtime migration requires the key to already exist on the target before migration starts. That is a vendor limitation, not a Hyper-V gap. For the native mechanisms above, no fallback is needed: attested guarded hosts migrate shielded VMs live by design.

Verification before acting

1. Inside the guest, run manage-bde -status to see whether BitLocker is guest-side.
2. On the hosts, run Get-HgsClientConfiguration and Get-VMKeyProtector to detect a shielded VM configuration.
3. If volume-level encryption is suspected, check Get-BitLockerVolume on the CSV owner node.
4. Rehearse a Live Migration in a lab with the identical configuration; a key-protector or attestation failure message confirms which layer applies.

Two cautions: shielded VMs require Datacenter edition, and admin-trusted attestation is deprecated in favor of TPM-trusted attestation — verify which mode your HGS uses. Also, migration of a shielded VM to a host outside the trusted fabric fails by design; that is the security boundary working, not a bug to route around.