Proxmox Secure Boot and TPM 2.0 Setup for KVM Guests

Proxmox VE 9.1 can present UEFI Secure Boot and a virtual TPM 2.0 to KVM guests by attaching an EFI disk and a TPM state disk to the VM. For new VMs, the setup is a short config change; for existing VMs, the guest must already be installed in UEFI mode. The concrete outcome is a boot chain that validates signed bootloaders and exposes PCR measurements without changing your storage or network layout.

Key Takeaways

Create fresh: build new guests with OVMF and a TPM state disk from the start.
Existing VMs: only convert guests that already use a UEFI bootloader on a GPT disk.
Guests matter: signed distros boot fine; custom kernels need MOK signing or disabled Secure Boot.
Backups first: take a backup before changing boot firmware, especially on production guests.
Tradeoff: boot integrity helps, but custom kernel and module workflows get more complex.

How to Create a Secure Boot VM in Proxmox VE 9.1

The cleanest path is to create the VM with UEFI firmware from the start. Proxmox stores UEFI variables and Secure Boot keys in a small EFI disk, and it stores the virtual TPM state in a separate disk. On my test node, the EFI disk is 4 MB and the TPM state disk is 1 MB, so the storage cost is trivial.

The command below creates a Linux VM with the q35 machine type, OVMF firmware, an EFI disk with pre-enrolled keys, and a TPM 2.0 device.

qm create 100 --name secure-boot-test --machine q35 --bios ovmf --cpu host --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --scsi0 local-lvm:vm-100-disk-0,size=32G --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1 --tpmstate0 local-lvm:1,version=v2.0 --ostype l26

Start the VM and boot your installer. For Linux, choose the UEFI boot entry, not the legacy BIOS entry. For Windows 11, the installer should detect the virtual TPM and Secure Boot during setup.

What Proxmox Actually Adds

OVMF is the UEFI firmware image. It is what enforces Secure Boot inside the VM. The EFI disk keeps the UEFI variables, including the allowed signatures and the boot order. The TPM state disk keeps the TPM state across reboots and migrations.

The pre-enrolled keys option loads the standard Microsoft UEFI CA. That is enough for most mainstream Linux distributions and Windows. If you need your own Secure Boot keys, set the option to zero and enroll keys inside the guest firmware.

The virtual TPM is provided by the TPM software stack. It is usually present on a current Proxmox node, but if it is missing, install it with:

apt install -y swtpm

After that, the TPM state disk is managed by Proxmox; you do not need to run the TPM daemon by hand.

Storage Naming Notes

The examples use local-lvm because that is the default thin storage pool on a single-node Proxmox install. If your VM disks live on ZFS, Ceph, or NFS, replace the storage name in the command. The EFI disk and TPM state disk must live on a storage type that supports Proxmox volume management for those devices.

How to Add Secure Boot and TPM to an Existing VM

You can add the same options to an existing VM, but only if the guest was installed in UEFI mode. If the guest was installed with a legacy BIOS bootloader on an MBR disk, Proxmox will give it UEFI firmware, but the guest will not boot from the existing bootloader.

Back up the VM. This is the step people skip, and it is the one that saves you later.
Stop the VM completely. The boot firmware and machine type cannot be changed while the guest is running.
Apply the UEFI and TPM settings with the command below.
Start the VM and confirm the boot mode inside the guest.

qm stop 100
qm set 100 -bios ovmf -machine q35 -efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1 -tpmstate0 local-lvm:1,version=v2.0
qm start 100

After the change, the VM config on the Proxmox node will look similar to this:

bios: ovmf
machine: q35
efidisk0: local-lvm:vm-100-disk-1,efitype=4m,pre-enrolled-keys=1
tpmstate0: local-lvm:vm-100-disk-2,version=v2.0

The generated volume names may differ. The important part is that the EFI disk and TPM state disk exist and point to storage that the node can manage.

What the Guest OS Needs to Boot

Secure Boot is a guest-side trust chain, not just a Proxmox checkbox. The firmware checks the bootloader, the bootloader checks the kernel, and the kernel checks its modules. If any link in that chain is unsigned, the boot can fail.

For mainstream Linux distributions, the installer usually handles this. Ubuntu, Fedora, and recent Debian releases use signed shim and grub components on supported architectures. Once installed, the guest should boot with Secure Boot enabled.

If you run a custom kernel, you need to sign it with a key enrolled in the guest firmware. This is usually done through the Machine Owner Key process. The same applies to out-of-tree kernel modules. A common gotcha is a working custom kernel that boots only after you sign the kernel image and every DKMS module, or after you enroll the signing key in the guest firmware.

On a Linux guest with the required tools installed, you can check the Secure Boot state with:

mokutil --sb-state

If the guest does not have the tool installed, use the distribution’s own security or boot tools. The exact package varies, so it is better to test in a VM before making this a production standard.

Linux and Windows Behavior Under Secure Boot

Linux guests are usually straightforward when they are installed from supported media. The problem starts when sysadmins add DKMS modules, custom kernels, or unusual initramfs hooks. If Secure Boot blocks a module, the guest may boot but the module will not load. That can look like a missing network driver, a missing storage driver, or a failed TPM user-space tool.

Windows guests have different expectations. Windows 11 expects TPM 2.0 and Secure Boot, and Proxmox can satisfy both with the options above. The guest must still have signed drivers. If you are building the Windows guest from scratch, the Windows 11 VM on Proxmox with VirtIO setup steps still apply; Secure Boot only changes the boot path.

For Windows performance, the usual VirtIO advice still applies after Secure Boot is enabled. The Windows VM performance tuning swaps emulated devices for VirtIO guide remains the right follow-up once the VM boots.

For Linux guests that use ZFS on the host, Secure Boot does not change the host storage stack. But if you run ZFS kernel modules inside a Secure Boot guest, you need signed modules. That adds a small operational cost, and it is a real tradeoff for homelabs that like to build kernels for fun.

Comparison Table for Proxmox Secure Boot Options

The table below maps the main Proxmox options to what they do and when you should use them.

Option	What it does	Use it when
bios set to ovmf	Switches the VM from legacy BIOS to UEFI firmware.	The guest is installed or will be installed in UEFI mode.
machine set to q35	Uses the Q35 machine type required by OVMF on Proxmox.	Any UEFI VM.
EFI disk with 4 MB type	Stores UEFI variables, Secure Boot keys, and boot order.	Secure Boot is enabled.
pre-enrolled-keys enabled	Loads the standard Microsoft UEFI CA into the guest firmware.	You want standard Windows and signed Linux distros to boot.
TPM state with version 2.0	Adds a virtual TPM 2.0 device backed by stored state.	Windows 11, Linux TPM measurements, or attestation workflows.
pre-enrolled-keys disabled	Starts with an empty Secure Boot key store.	You need custom keys and will enroll them manually.

Common Failure Modes and Fixes

A VM boots with SeaBIOS but fails after switching to UEFI. The guest probably has an MBR bootloader. Convert it to a UEFI bootloader on GPT, or reinstall.
Secure Boot blocks a custom kernel. Sign the kernel and modules, or enroll a custom key in the guest firmware.
The guest boots but the TPM is missing. Confirm the TPM state disk exists and the machine type is q35.
A Windows guest complains about TPM. Confirm the TPM state disk is present and the guest sees a TPM 2.0 device.
The VM fails to start after moving storage. The EFI or TPM state disk may not be available on the target storage.

Before touching a production guest, take a backup; if you are running PBS, PBS 4.2 parallel sync jobs can shrink the window. Even on a small homelab, a few seconds of backup time is much cheaper than debugging a guest that no longer boots.

Migration and Cluster Notes

If you are moving VMs between nodes, the EFI disk and TPM state disk must be available to the destination node. Shared storage makes this simple. Local storage does not, unless you move the disks or use a storage backend the cluster can see.

Live migration works for running VMs with these settings, but I would not test that for the first time on a production guest. Stop the VM, move it, start it, and confirm the guest still sees the TPM. That sequence takes about 10 minutes per VM on a small cluster, and it gives you a clean failure point if something goes wrong.

For clusters, the same command syntax applies. The only change is the storage name. If you use ZFS replicated storage, make sure the EFI and TPM volumes are included in whatever replication or backup process you rely on.

Security Notes Without the Marketing

Secure Boot is not full disk encryption. It does not protect data at rest. It protects the boot chain from unauthorized bootloaders and kernels. TPM 2.0 can extend that story with measurements, but it does not do that automatically.

If you want TPM-backed encryption, you need a guest-side policy. On Linux, that can mean systemd-cryptenroll or another tool. On Windows, it can mean BitLocker with TPM protection. Proxmox supplies the device; the guest OS decides what to do with it.

The practical value is higher assurance on boot integrity. The practical cost is more moving parts when you build custom kernels, sign modules, or move VMs between storage pools.

Conclusion

Proxmox VE 9.1 makes Secure Boot and TPM 2.0 practical for normal KVM workloads, as long as the guest is installed in UEFI mode and the EFI and TPM state disks are present. New guests are a quick win: create them with OVMF, q35, an EFI disk, and a TPM state disk. Existing guests need a careful boot-mode check before you flip the settings. Your next step is to pick one test VM, back it up, apply the settings, and confirm the guest boots with its expected boot chain.