V2K MigrateA disk conversion can finish successfully and still leave you with a guest asking for a BitLocker recovery key. That's why the vTPM needs to show up in the migration checks.
01 / Why it matters
The device is virtual. Its trust is not portable.
BitLocker, measured boot or an application may depend on the source vTPM. Copying the VMDKs doesn't copy that device's state. A new vTPM on the destination won't have the old keys or satisfy the same attestation checks just because the disks are there.
We don't guess from the Windows version. A VM can have a vTPM without using it for BitLocker, and another workload may depend on it for application keys. Device presence and guest dependency are two different things.
02 / What changed
Inventory reads the virtual hardware list.
During vCenter inventory sync, V2K reads
VirtualMachine.config.hardware.device. If that list contains a
VirtualTPM device, V2K stores one boolean: present or not present.
It does not collect certificates, key material or TPM state.
Preflight uses that value to warn against the affected VM. In a plan with many workloads, you can see exactly which guest needs attention.
V2K Migrate does not copy source vTPM state, certificates, sealed objects or key material. If a destination integration provisions a vTPM, it is a new, empty device.
Destination behaviour differs. CloudStack and storage-only report a warning, while Proxmox NFS/QCOW2 stops the VM in preflight because it cannot reproduce the key-backed state. Having a vTPM doesn't necessarily mean the guest needs it to boot. That still needs checking inside the guest.
03 / Before cutover
V2K can find the device. It cannot inspect the dependency.
The tool tells you which VMs have a vTPM, and it tells you before the source is shut down. It cannot know whether BitLocker, measured boot or an application inside the guest depends on that TPM.
Before shutting down the source, check the guest and confirm that its recovery keys exist somewhere outside the VM. If it needs a new destination vTPM, plan the re-enrolment or re-protection before cutover.
Once migrated, test boot and access to protected volumes.
04 / What's included
This change stops at detection and warning.
Discovery and the preflight warning are implemented. Automatic recovery of TPM-protected workloads is not part of this change.
The current CloudStack and storage-only paths do not create a destination vTPM. Proxmox NFS/QCOW2 goes further: it blocks a source VM with a vTPM in preflight because it cannot reproduce the key-backed state.
A future destination integration may create a new, empty vTPM, but it will have no relationship to the source device. V2K will not describe that as preserved or migrated.