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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
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.
Related prompts
-
Nova Flavor Extra-Specs & Aggregate Scheduling Design Prompt
Design a clean flavor catalog with extra-specs and host-aggregate metadata so workloads land on the right hardware (GPU, high-mem, fast-NVMe) via the AggregateInstanceExtraSpecsFilter.
-
Kolla-Ansible passwords.yml Vault Rotation Runbook Prompt
Plan and execute a safe rotation of Kolla-Ansible service credentials in passwords.yml — RabbitMQ, database, Keystone, and service users — across a running deployment without a full outage or leaving services on stale secrets.
-
Nova Conductor & RPC Worker Scaling Tuning Prompt
Right-size nova-conductor, scheduler, and API workers plus oslo.messaging RPC pools so the control plane stops timing out under fleet growth — without over-provisioning RabbitMQ connections or starving the database pool.
-
Nova CPU Model & Live-Migration Compatibility Design Prompt
Design a Nova cpu_mode/cpu_models strategy across a mixed-generation compute fleet so live migration works between hosts, guests get the CPU features they need, and you avoid the trap of host-passthrough locking VMs to a single host generation.
More OpenStack prompts & error guides
Browse every OpenStack prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.