Skip to content

Virtualized hosts

Most Linux estates run on a hypervisor, so this is the normal onboarding path, not an exception. A vTPM presented by your hypervisor is a TPM 2.0 device as far as the agent is concerned: the same /dev/tpmrm0, the same SHA-256 PCR 10, the same quote. Nothing in the agent or the verifier is aware it is virtual.

What this chapter covers is the one prerequisite that differs from bare metal — giving the guest a vTPM in the first place — for the four hypervisors that carry the regulated European Linux estate.

How far each section has been walked

Be told this before you follow one. Etminan's own laboratory runs on QEMU/OVMF with a vTPM, and a guest there enrols and attests — so the platform works. But the steps below have not been walked start to finish for any hypervisor, and no Proxmox, vSphere or Hyper-V environment exists on our side to walk them on. The vSphere and Hyper-V sections are written from vendor documentation rather than from a run.

That is not a reason to avoid them; it is a reason to expect a rough edge and to tell us when you hit one. If a step is wrong we would rather hear it from you than keep publishing it.

Read the trust statement first

A vTPM on a hypervisor you own proves the guest OS was not tampered with from the inside, and your trust perimeter is unchanged. It does not prove the TPM is silicon. The full per-deployment-class table is in Requirements — read it before rolling out, because it is what an assessor will ask about.

Common prerequisites

Independent of hypervisor, every guest needs all four:

Prerequisite Why
UEFI firmware (not legacy BIOS) vTPM devices attach to the UEFI machine model on every platform here.
A vTPM 2.0 device TPM 1.2 is out of scope — Etminan uses the SHA-256 PCR bank exclusively.
An IMA-capable kernel Unchanged from bare metal; the distro kernels of the supported distributions qualify.
A supported guest distribution The agent links the distro's tpm2-tss.

After the guest boots with a vTPM, confirm it inside the VM before installing anything:

# The resource-managed node the agent uses must exist
ls -l /dev/tpmrm0

# The SHA-256 bank of PCR 10 must be present
ls /sys/kernel/security/ima/ascii_runtime_measurements_sha256

If /dev/tpmrm0 is missing but /dev/tpm0 exists, the kernel's TPM resource-manager module is not active — the agent needs tpmrm0 and will not fall back to the raw device.

Proxmox VE

Proxmox is the fastest path and needs no key-management infrastructure.

  1. Select the VM → Hardware → Add → TPM State.
  2. Choose a storage for the TPM state volume and set Version: v2.0.
  3. Under Options → BIOS, confirm OVMF (UEFI) — with an EFI disk added. A vTPM cannot attach to a SeaBIOS guest.
  4. Machine type q35 on x86_64 (virt on an arm64 host).
  5. Stop and start the VM. A reboot from inside the guest is not enough for the new device to appear.
# add a TPM 2.0 state volume on <storage>
qm set <vmid> --tpmstate0 <storage>:1,version=v2.0

# confirm the guest is UEFI + q35 (use --machine virt on an arm64 host)
qm set <vmid> --bios ovmf --machine q35

qm stop <vmid> && qm start <vmid>

Proxmox on arm64: vTPM does not work yet

Etminan requires an x86_64 Proxmox host today. On the arm64 edition (PVE 9.2) qm set --tpmstate0 reports success but the VM then refuses to start — Proxmox emits the x86 device model tpm-tis, which aarch64 QEMU does not have. Even patched past that, an arm64 Debian guest cannot anchor IMA in the TPM at all: the kernel logs "No TPM chip found, activating TPM-bypass" before the TPM driver loads, so PCR 10 is never extended while the measurement log keeps filling normally. Both were measured on 2026-08-09. The agent itself is x86_64-only regardless — see Requirements.

KVM / libvirt

The host needs swtpm and swtpm-tools installed; libvirt then manages the emulator per domain.

Add inside <devices>:

<tpm model='tpm-crb'>
  <backend type='emulator' version='2.0'/>
</tpm>

tpm-crb is the right model for x86_64 UEFI guests. The domain must already use OVMF firmware (<loader ... type='pflash'>).

virt-install \
  --boot uefi \
  --machine q35 \
  --tpm backend.type=emulator,backend.version=2.0,model=tpm-crb \
  ...

VMware vSphere

vSphere is the one platform with a hard prerequisite outside the VM: vTPM state is encrypted, so the cluster needs a configured key provider before a vTPM can be added at all.

  1. Configure a key provider on the vCenter — the Native Key Provider is sufficient and needs no external KMS. Back up its key material; without it, VMs with a vTPM cannot be powered on after a restore.
  2. The VM must use EFI firmware with Secure Boot enabled, and a sufficiently recent VM hardware version.
  3. Edit Settings → Add New Device → Trusted Platform Module.

Do not clone a VM that has a vTPM

Cloning replaces the vTPM state, which changes the endorsement key. To Etminan that is a different TPM: the clone's AK will not match the enrolled fingerprint and the host must be re-enrolled with --force after confirming the new fingerprint out of band. Build the template without a vTPM and add one per deployed VM.

Hyper-V

Requires a Generation 2 VM. Standalone hosts (no Host Guardian Service) use a local key protector:

# once per VM, before enabling the vTPM
Set-VMKeyProtector -VMName <vm> -NewLocalKeyProtector
Enable-VMTPM -VMName <vm>

In the UI the same setting is Settings → Security → Enable Trusted Platform Module. As with vSphere, the key protector is host-local state — export it if the VM may ever be moved or restored elsewhere.

Rebooting a guest

A guest reboot is ordinary. It needs nothing from you.

This page used to say otherwise. It described emulated TPMs losing PCR-10 ↔ IMA-log consistency across a reboot, called it a property of the platform, and told you to treat a PcrDigestMismatch after a planned reboot as expected rather than as a finding. That was wrong on both counts, and the second half was dangerous: it asked you to ignore the strongest accusation this product makes.

What was really happening was our defect. Measured on a lab guest on 2026-08-30: the host's IMA log replayed from zero to exactly the PCR-10 value its TPM had signed — verified with an implementation independent of Etminan — so the host was honest. The verifier was replaying from a stored cumulative that belonged to the previous boot, and no emulated TPM was involved in the mistake.

What happens now. Before the verifier calls a mismatch tampering, it asks the host once more from offset zero. If that replay reaches the digest the TPM signed, this was a reboot: the verifier adopts the new cumulative and carries on with a note, not an alarm. The host recovers by itself and nobody re-enrolls anything.

This is evidence rather than a guess. The replay must still reach the TPM-signed digest, so a host gains nothing by claiming to have rebooted. A log that cannot reach that digest from zero still raises the critical finding, and that is the case worth waking up for.

So a PcrDigestMismatch is never something to expect and wait out. If you see one now, the re-read from zero has already failed, and it means what it says.

Next steps

  • Install the agent in the guest — from here the procedure is identical to bare metal.
  • Enroll it without --ek-roots: a vTPM presents no manufacturer EK certificate, and the flag refuses such a host by design.