Nova vTPM & Emulated Secure Boot Flavor Design Prompt
Design Nova flavors and image properties for vTPM and UEFI Secure Boot so confidential/Windows workloads boot with measured boot and a persistent TPM, validated before fleet use.
- Target user
- Advanced Nova operators enabling vTPM / Secure Boot
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Nova operator who enables vTPM and UEFI Secure Boot on KVM/libvirt computes. I will provide: - OpenStack release, libvirt/qemu/swtpm versions, and the OVMF/edk2 firmware available on computes - Barbican status (vTPM data is encrypted via the key manager) and the `[key_manager]` config - Target image properties (`hw_firmware_type=uefi`, `os_secure_boot`, `hw_tpm_version`, `hw_tpm_model`) and the flavor extra-specs - The workload (e.g., Windows 11, confidential VM) and the symptom if debugging: boot fails, Secure Boot rejects the image, TPM not present, or migration loses the vTPM - libvirt domain XML and nova-compute logs around the boot Your job: 1. **Prerequisite audit** — confirm swtpm, edk2/OVMF Secure Boot firmware, and Barbican are present, since vTPM persistence requires the key manager. 2. **Property mapping** — assemble the exact image properties + flavor extra-specs for the desired combination (UEFI, Secure Boot on/off, TPM 1.2 vs 2.0, CRB vs TIS). 3. **Persistence & migration** — explain how the vTPM state is stored/encrypted and what happens on live-migrate/evacuate (and how to avoid losing it). 4. **Failure diagnosis** — if booting fails, isolate firmware vs Secure Boot key DB vs TPM emulation vs Barbican as the cause. 5. **Compute readiness** — which hosts qualify (traits/aggregates) so scheduling only lands these flavors on capable nodes. 6. **Validation** — an in-guest check (TPM present, Secure Boot enabled) and a migration test before declaring the flavor production-ready. Output as: (a) an image-property + extra-spec matrix per workload, (b) a compute-readiness/trait plan, (c) a boot + migration validation checklist. Validate boot AND live-migration of a vTPM instance on capable hosts before publishing the flavor; ensure Barbican is healthy since losing the key manager can render vTPM data unrecoverable.
Why this prompt works
vTPM and Secure Boot enablement is a stack of prerequisites where any missing layer produces a confusing boot failure: swtpm must be installed, edk2/OVMF must include Secure Boot firmware, and Barbican must be healthy because the vTPM state is encrypted through the key manager. Operators typically set the image properties, hit a boot failure, and have no framework for isolating which layer is missing. This prompt makes the prerequisite audit the first step and forces a property-to-extra-spec matrix, so the configuration is assembled deliberately rather than copied from a forum post.
The persistence-and-migration analysis addresses the risk that catches teams in production: a vTPM has state, that state is sealed and encrypted, and live-migration or evacuation can lose it if not handled correctly. Worse, because the state depends on Barbican, a key-manager problem can render TPM-sealed data unrecoverable. By making the model explain persistence and require a migration test, the prompt forces these failure modes into the open before a workload depends on them.
The compute-readiness and trait step closes the scheduling gap. Not every host can run vTPM/Secure Boot, and without traits or aggregates the scheduler will happily land these flavors on incapable nodes and fail boots intermittently. Requiring an in-guest validation plus a migration test before publishing the flavor keeps the human firmly in the verification loop — the AI assembles the configuration matrix, the operator proves it boots, migrates, and only lands where it can succeed.