Add a vTPM to Windows Server guests on OpenStack: image properties or flavor extra specs, swtpm on compute hosts, Barbican for keys, and limits.
A Windows requirement that asks for a TPM lands on the infrastructure leads and platform teams who run Windows Server workloads on OpenStack, or are moving them there from vSphere. On OpenStack, meeting it means giving each guest a vTPM.
Sometimes the requirement comes from Windows itself. Microsoft's Windows Server system requirements say certain features need a TPM, BitLocker Drive Encryption among them, and that hardware TPMs must be version 2.0.
Desktops bring their own deadline. Windows 10 reached end of support on October 14, 2025, and Windows 11 lists TPM 2.0 among its hardware requirements. Intune's compliance settings for Windows 10 and later also include a TPM rule that reports a device without one as not compliant.
Without a vTPM, a Windows Server guest can't use TPM-backed BitLocker, and a Windows 10 or 11 desktop VM fails a policy that requires a TPM. Adding a vTPM without an operating plan moves the risk to day two. Moving a BitLocker-protected disk to a new VM can trigger recovery, so your team needs access to its recovery information.
That leaves your team three decisions. Do your projects request vTPMs through image properties, or do your operators publish vTPM flavors? Are your compute hosts ready? Who owns operations and recovery for these guests?
Nova provides the device as an emulated vTPM and has done so since the Victoria release. This post covers only the TPM. Windows 11 and Microsoft's Secured-core server both list firmware and platform requirements beyond it.
Image or flavor
Nova reads the same two settings from either place. On an image, they're the properties hw_tpm_version and hw_tpm_model. On a flavor, they're the extra specs hw:tpm_version and hw:tpm_model.
The version is 1.2 or 2.0, and setting it requests a vTPM. The model is tpm-tis, the default, or tpm-crb, which only works with version 2.0. For Windows Server, use 2.0. Our Atmosphere vTPM documentation recommends it.
Which place you use depends on who has permission, and that decides who can start a BitLocker rollout first. If a project member uploaded the Windows image, they can set its properties without operator access:
openstack image set --property hw_tpm_version=2.0 --property hw_tpm_model=tpm-crb <image>
From then on, every server built from that image asks for a vTPM, whatever flavor it boots on. Our documentation points to this route for Windows versions that won't run without a TPM. After the first boot, run the Get-Tpm cmdlet inside the guest. Its TpmPresent field shows whether Windows sees a TPM.
Setting a flavor extra spec takes an operator. Use it when your cloud wants a named vTPM size in its catalogue, so the device follows the size whichever image a tenant boots. If the image and the flavor disagree, or tpm-crb is paired with 1.2, Nova fails the request at scheduling.
If your Windows Server VMs are coming from vSphere, add the vTPM setting to each image's entry in your migration plan, next to the flavor size you map it to.
The host side
Nothing on the image works until the compute host can emulate the device. Nova's vTPM guide lists what each host needs:
- Hypervisor. The libvirt driver, with
virt_type set to kvm or qemu. Our post on the OpenStack hypervisor stack follows the path from nova-compute through libvirt and QEMU to KVM. - Emulator. The swtpm binary and its libtpms libraries on every compute node, plus
swtpm_enabled set to True in the libvirt section of nova.conf. - Key manager. A service such as Barbican, which holds the secrets that encrypt each vTPM at rest.
Once a host qualifies, it reports the traits COMPUTE_SECURITY_TPM_1_2 and COMPUTE_SECURITY_TPM_2_0 on its resource provider. List a compute node's traits before the first compliance review that depends on these guests.
On Atmosphere, the host side is already done. Atmosphere sets swtpm_enabled to true in its Nova defaults, with a dedicated swtpm user and group. It also deploys Barbican and points Nova at Barbican's internal endpoint. The work left is to set the image property or the flavor.
If you build on upstream OpenStack yourself, the host side is your team's work. You package swtpm on each compute node, roll out the nova.conf change, and run Barbican as a production service with its own backups and upgrades. Our Barbican overview explains what the service does.
Where the vTPM state lives
Each vTPM is an encrypted file on the compute host. Nova keeps its passphrase in the key manager, tied by default to the server owner's credentials. At each boot, libvirt fetches the passphrase and holds it as a private, ephemeral secret.
That design leaves three things to plan.
- Owner-run operations. In the default secret mode, decrypting the file needs the owner's credentials. Nova's guide says server operations on these guests are supported when the owner runs them. For an admin to act on them, your deployment may need extra policy roles or key manager ACLs. Decide who can stop, start and reboot a Windows guest before the first one holds production data.
- Rebuild, evacuate, shelve and rescue. Nova lists these as unsupported for servers with a vTPM. If a compute host fails, you can't evacuate a Windows guest with a vTPM to another host, so recovery for these guests runs through your backups and the application's own redundancy.
- BitLocker recovery keys. Microsoft lists clearing the TPM, and moving a BitLocker-protected drive into a new computer, among the events that trigger BitLocker recovery. Before an encrypted Windows Server VM moves from vSphere, store its recovery key where your team can reach it.
Our part in a vTPM rollout
We made the vTPM default in Atmosphere ourselves. A November 2024 commit set swtpm_enabled to true in our Nova defaults, and it has stayed on since.
Our operators do the same kind of host-level work for compute security. When CVE-2026-53359, a KVM/x86 compute isolation issue, became public in July 2026, we published our assessment. It covers the host review and the patched-kernel rollout operators should plan.
Superuser's 2018 profile of Vanilla Forums covers a period when we ran both of the company's private OpenStack clouds, one in Montreal and one in the US. Its hosting footprint grew sixfold while its ops team stayed the same size.
You can work with us on this in two ways. With support, your operators run the cloud and our engineers back them up. With management, we run it, in your data center or ours. Our On-Premise edition runs Atmosphere in your own facility, with either support or remote operations from us. If someone else deployed your cloud, our professional services consultants still work on it, however it was installed and configured.
For Windows Server guests, Atmosphere brings KVM compute, swtpm in Nova and Barbican together in one open-source deployment built with Ansible, Helm and Kubernetes. The Nova defaults that turn vTPM on are public in the repository, so your operators can audit them before any guest depends on them.
If your team is working toward a BitLocker or compliance deadline for its Windows Server guests, collect four inputs: the Nova release your cloud runs, the images that need a vTPM, the people who should own operations on those servers, and a recovery plan for guests that can't be evacuated. Bring that list to a consultation call and we can walk it through an Atmosphere deployment with you, ending on the first decision: image properties set by your projects, or vTPM flavors owned by your operators.
