An OpenMetal XL v5 node arrives with Intel TDX enabled out of the box. It ships 1 TB as sixteen 64 GB DDR5-6400 modules, which fills Slot 0 of every memory channel symmetrically across both sockets, and that is exactly the population Intel’s TDX module requires before it will initialize. No memory upgrade, no special order, no waiting on a lead time. A workload that needs its memory encrypted from the host can land on that node the day it racks.
Confidential computing is usually sold as a premium tier you migrate onto. Here it is a property of hardware you already lease at a fixed monthly cost. There is no confidential-instance SKU with its own meter, no per-feature surcharge for the trust boundary, and nothing to re-architect when a compliance requirement arrives mid-project. The workloads this opens up are the ones that cannot go on shared infrastructure at all: protected health information under a Business Associate Agreement, financial records, multi-party data collaboration where no participant will hand another plaintext, and proprietary model weights and the prompts that flow through them.
The next thing to arrive is OpenStack orchestration on our Hosted Private Cloud. Intel TDX support for the libvirt compute driver is an approved blueprint accepted for OpenStack Nova 2026.2 Hibiscus, with implementation underway. When that lands upstream and OpenMetal implements on top of it, a Trust Domain becomes something the cloud declares, places, and rebuilds like any other instance, instead of something an operator builds against the host directly. The hardware requirement for that future is the same requirement v5 already satisfies, so the path is additive rather than a different purchase.
Key Takeaways on how OpenMetal supports TDX
- TDX can be enabled out of the box on XL v5. The shipped 16 x 64 GB fill already satisfies Intel’s channel-population gate, so confidential workloads can run from day one with no upgrade.
- Single-tenant bare metal makes the attestation chain yours. No co-tenant and no provider hypervisor sits underneath, so you can measure the chain of trust end to end yourself.
- The same memory fill pays three ways. Full channel population satisfies the TDX gate, reaches peak DDR5-6400 bandwidth, and leaves room for the largest SGX enclave the silicon supports.
- Nova 2026.2 Hibiscus is slated to add orchestration on top. The Intel TDX libvirt blueprint is approved and in progress upstream, ahead of the August feature freeze.
- A preconfigured platform is how upstream features reach production. OpenStack at OpenMetal runs containerized through Kolla-Ansible against known-good configurations, so a new driver capability is a tested platform change.
What runs today, and the arithmetic behind it
Intel TDX builds its protections on multi-key total memory encryption implemented in the integrated memory controllers. The module needs every controller channel present and symmetric to manage encrypted memory and its metadata coherently, and the platform firmware enforces that before exposing the toggle: first slot of every channel populated, at least eight identical DIMMs per socket, symmetric across sockets.
On the 8-channel Granite Rapids platform with fleet-standard 64 GB modules, that gate and OpenMetal’s 1 TB production spec are satisfied by the same fill. The design intent is that you do not choose between them:
Per socket: 8 channels x 64 GB = 512 GB (Slot 0 of every channel)
Two sockets: 16 DIMMs x 64 GB = 1024 GB (symmetric, gate satisfied)Watch the per-socket figures: “8 x 64 GB” read as a system total is 512 GB and does not reach 1 TB.
PAMT metadata reserved before any Trust Domain launches, approximately RAM / 256: 1024 GB / 256 = ~4 GB reserved 512 GB / 256 = ~2 GB reserved, against half the usable envelope “`
That arithmetic is why 1 TB is the production tier. Intel’s published TDX overhead figures, roughly 3% on SPECrate and roughly 4.5% on memory-latency-sensitive SPECjbb, were measured on a two-socket platform with 1 TB in 16 x 64 GB, so a 1 TB node is the configuration those numbers actually describe. It also keeps 512 GB local to each socket, which matters because encrypted cross-socket access over UPI carries its own latency on top of local memory encryption.
Owning the host is what makes the trust chain verifiable
A confidential VM is only as meaningful as the chain of trust you can inspect. On a shared confidential instance you are still trusting the provider’s host stack and control plane to have stood the trust domain up correctly, and you cannot see most of it. OpenMetal runs these nodes as single-tenant bare metal with root access, so there is no co-tenant on the box and no managed hypervisor between your code and the silicon. You bring the host operating system and the hypervisor, and you launch the Trust Domain yourself.
The practical payoff is inspection. The chain from the Granite Rapids CPU’s trust domain outward is yours to measure, attest, and re-attest on your own schedule and against your own policy, rather than something you accept on a provider’s word. For a regulated workload that difference tends to be the whole conversation with an auditor, because the question is never only whether memory was encrypted, it is what evidence you hold that it was.
OpenMetal holds HIPAA at the organizational level and can sign a Business Associate Agreement. Certifications such as SOC 2 and ISO 27001 are held by the data center facility operator at the moment, and they apply at the facility level rather than to the OpenMetal platform.
Where a GPU belongs inside that boundary, the mechanism is specific and supported: the card is bound to VFIO passthrough and assigned to the Trust Domain, the NVIDIA driver opens an attested SPDM session with it, and transfers cross the PCIe bus through encrypted bounce buffers. The supported unit is one GPU per confidential VM, so size a confidential inference unit around a single card and scale out by adding Trust Domains, each with its own. Where a node carries two cards those are two discrete accelerators rather than a pooled one. Because the supported stack is version specific across the confidential-computing driver branch, the Granite Rapids TDX module, matched host and guest operating systems, host-side GPU confidential mode, and guest attestation with driver persistence, this arrives as a configured build that the OpenMetal Engineering team validates against your specific workload rather than as a self-serve toggle. Attestation work is in progress, and an end-to-end CPU-to-GPU round trip has not yet been validated.
For a workload that fits an enclave rather than a full encrypted VM, Intel SGX is enabled by default today on both bare metal and HPC nodes, with a 128 GB enclave page cache per socket on XL v5. That path needs none of the orchestration work below.
What Nova 2026.2 Hibiscus adds
Everything above works without OpenStack in the picture. An operator with root can enable TDX in firmware, bring a hypervisor, and run Trust Domains today, which is the shape of the offer and the reason TDX is a bare-metal capability here rather than a Hosted Private Cloud guest feature.
Orchestration adds a different layer of value: fleet lifecycle. A cloud earns its keep by owning placement, tracking what each host has left, enforcing quota, and rebuilding an instance elsewhere when a host fails. Applying those functions to a Trust Domain requires the capability to be expressed where the scheduler can query it, which means inside the compute driver. That is precisely the gap the upstream work closes.
Intel TDX confidential VM support for the libvirt driver is an approved Nova blueprint accepted for the 2026.2 Hibiscus cycle, with definition and direction both approved and implementation started. It cleared Nova’s spec freeze on 11 June 2026 and patches are in review. For an operator tracking it, the date that matters is the Hibiscus-3 feature freeze in the week of 24 August 2026, after which no featureful patch lands, ahead of the coordinated release on 30 September 2026. The work builds on Nova’s existing AMD SEV and SEV-ES support and coordinates with in-flight SEV-SNP and ARM CCA efforts, so confidential VMs are getting sustained upstream attention rather than a single contribution. The SEV-SNP companion is not applicable here, since the OpenMetal fleet is Intel only.
The upstream floor is specific, and it is checkable against your own compute nodes:
| Component | Minimum for the Nova TDX path | What it contributes |
|---|---|---|
| Linux kernel and KVM | 6.16 | Host-side TDX module support and Trust Domain lifecycle |
| QEMU | 10.1 | Machine-type and launch-security plumbing for a Trust Domain |
| libvirt | 11.6.0 | Exposes the launch security type Nova’s driver drives |
| OpenStack Nova | 2026.2 Hibiscus, blueprint approved and in progress | Turns the capability into a schedulable instance property |
The host-side probe that shows whether the stack is in play is the same one used for the existing confidential-VM types:
virsh domcapabilities | grep -i -A3 launchSecurity
An approved blueprint is upstream work on an upstream schedule, not merged code, so OpenMetal would implement after Hibiscus lands rather than ahead of it.
We are open to working with customers to validate these workloads on OpenMetal’s private cloud as that happens, and a proof of concept on real hardware now is how a team gets ready for it. Until then TDX remains a bare-metal capability here.
What makes an upstream release reach production quickly is the platform underneath it. OpenStack services here run in containers deployed through Kolla-Ansible against known-good, tested configurations, so a new libvirt-driver capability is a change to a validated deployment rather than a bespoke integration rebuilt for every customer. That is the difference between a feature existing upstream and a feature you can actually run.
What this looks like on OpenMetal
| Product and link | XL v5 bare metal dedicated server, or the XL v5 TDX configuration |
| Delivery model | Single-tenant bare metal, one dedicated node, no oversubscription and no co-tenant |
| Access | Root, full firmware and driver control, your own hypervisor or none |
| Base configuration | 2x Intel Xeon 6530P (Granite Rapids, Intel 3), 64C/128T, 1 TB DDR5-6400 as 16 x 64 GB, TDX enabled out of the box, SGX enabled with a 128 GB enclave page cache per socket |
| What you must add | Nothing for the TDX gate. The shipped 16 x 64 GB already fills Slot 0 of all 8 channels on both sockets, which is the population the firmware requires. On Medium v5 or Large v5, fill the 8 open slots first; memory pricing and lead time are quoted at the time of order |
| Local storage | 2x 960 GB M.2 boot pool held off the data path, plus 4x 6.4 TB Micron 7500 MAX NVMe, expandable to 12 drives total |
| Network | 2x 10 Gbps default (20 Gbps private), 6 Gbps public, upgradeable to 4x 10 Gbps at additional cost |
| Software boundary | OpenMetal provides the node with TDX exposed in firmware, and an opinionated Kolla-Ansible OpenStack where a cloud is in scope. For TDX today you bring the host OS, hypervisor, and guest stack. The Nova-orchestrated path depends on the upstream work above |
| Validation path | A proof of concept on your own workload. OpenMetal Engineering validates the specific configuration, and we are open to working with customers to validate these workloads on our private cloud |
| Pricing path | See bare metal pricing, or request a quote for a TDX configuration |
Your next confidential workload belongs on OpenMetal
Route on what the workload needs and when. If it needs an encrypted VM this quarter or next, it belongs on bare-metal TDX now, on a node whose memory fill already satisfies the gate, with your hypervisor above it. If it fits an enclave rather than a full VM, SGX is enabled today on both bare metal and HPC nodes and needs nothing further.
And if what you want is confidential compute your cloud schedules, quotas, and rebuilds like everything else, run the proof of concept on bare metal now so the workload is characterized and ready as the upstream work for OpenStack orchestration lands, and bring us in to validate it with you.
The hardware is in place, the trust boundary runs today, and the orchestration is arriving on top of a node you would buy either way.