vMetal
vMetal provisions and manages physical and virtual machines. It boots bare metal servers over the network, installs an operating system, configures networking, and tracks which servers are claimed and which are free to reuse. The same model covers virtual machines through other drivers.
It is built for AI cloud providers and for teams running Kubernetes on hardware they own. A server is dedicated to one tenant at a time rather than shared.
vMetal runs as part of vCluster Platform. You need a Platform installation, a license that includes vMetal, and a connected Kubernetes cluster where Metal3 and Ironic can run. Handing out Machines without a tenant cluster also requires the machine-management license feature. See Requirements for the infrastructure prerequisites and Set up your hardware when you are ready to begin.
A Machine represents a claim on one provisioned server, physical or virtual. A driver is the integration that provisions and manages a specific infrastructure type, such as bare metal servers or virtual machines. See the Glossary for the full terminology and the Machine and server concepts page for the lifecycle and identity model.
Two use cases, three outcomes
vMetal serves two use cases as peers. Both use the same Machines, the same drivers, and the same pool of servers.
Stand up and hand out hardware. Request a Machine on its own and get a provisioned server with your SSH keys on it. Nothing installs Kubernetes. This is how you run vMetal as a metal-as-a-service layer, or as the foundation for workloads that are not Kubernetes at all.
Give tenant clusters dedicated capacity. Request a Machine for a tenant cluster and the provisioned server joins it as a Kubernetes node, with no manual join step. This use case has two shapes. A server can join as a worker, or it can carry the cluster's own control plane. The latter does not need a separate workload cluster to host the tenant control plane, but vMetal still needs the connected cluster where Metal3 and Ironic run.
That makes three things a provisioned server can become, and they differ by a field or two on the request. Everything up to the moment the operating system boots is identical, and all three share the same setup and day-2 operations. See Claim the server for the three side by side.
Evaluating vMetal
Work out whether vMetal fits your hardware and your team, before you set it up:
| If you want to... | Go to |
|---|---|
| Check vMetal works with your servers, BMCs, and network | Requirements |
| Run the whole provisioning flow with no hardware at all | Try it locally |
| See what to ask a data center or colocation provider for | Handoff checklist |
| Confirm your control plane cluster is a supported one | Managed Kubernetes restrictions |
| Understand what vMetal does not do | What vMetal does not provide |
| Know how long provisioning and reuse take | Turnaround expectations |
Trying it locally is the fastest way in. That guide runs Metal3, a NodeProvider, and simulated BareMetalHosts with Redfish BMC endpoints on KubeVirt VMs. You can watch a server provision end to end before any hardware arrives.
Where to start
Once you've decided to build on vMetal, here's where to go next:
Set up your hardware
Both use cases start here, whichever of the three a server ends up as.
| If you want to... | Go to |
|---|---|
| Provision your first bare metal server | Set up your hardware |
| Register many servers at once | Bulk registration |
| Configure a NodeProvider and node types | Configuration |
| Add, remove, and inspect servers | Operations |
| Diagnose a server that will not provision | Troubleshooting |
Hand out machines directly
| If you want to... | Go to |
|---|---|
| Provision a server with SSH access and no Kubernetes | Independently provisioned machines |
| Claim many servers at once | Scale to a fleet |
| Release a machine and return its server to the pool | Independently provisioned machines |
Give tenant clusters bare metal capacity
| If you want to... | Go to |
|---|---|
| Join servers to a tenant cluster as workers | Tenant cluster nodes |
| Run a tenant cluster's control plane on bare metal | Control plane machines |
| Scale nodes up and down safely | Change how many nodes you have |
| Apply reusable taints and labels to joined nodes | Node profiles |
| Understand how a server joins and what happens on scale-down | Cluster attachment |
| Automate node lifecycle instead of setting a fixed count | Auto Nodes |
Run AI workloads on it
| If you want to... | Go to |
|---|---|
| Understand GPU passthrough, vGPU, and MIG boundaries | GPU presentation modes |
| Provision GPU servers as tenant cluster nodes | GPU Quickstart |
| Hand out GPU servers over SSH instead | GPU Quickstart steps 1 to 3, then Independently provisioned machines |
| Build a GPU fleet for an inference provider | GPU Fleet Operations |
Understand the model
| If you want to... | Go to |
|---|---|
| Learn vMetal terminology | Glossary |
| Understand the Machine and server model and lifecycle | Machine and server concepts |
| Understand the Metal3 provisioning architecture | Architecture |
| See how servers join tenant clusters | Cluster attachment |
What the platform owns
The platform owns the NodeProvider, NodeType, and NodeClaim resources. A NodeClaim is the Kubernetes resource that represents one Machine request and tracks its lifecycle. Every use above creates a NodeClaim. They differ only in whether the claim names a tenant cluster and whether it is marked as a control plane.
Tenant clusters consume that capacity through Private Nodes, either at a count you set or maintained automatically by Auto Nodes. Auto Nodes is one way to consume vMetal capacity, not the whole of vMetal.
Driver portfolio
vMetal provisions Machines through a portfolio of drivers. Drivers differ in implementation form, maturity, and available features, so check each driver's own documentation before relying on a specific capability.
| Driver | Provisions | Status |
|---|---|---|
| Metal3 | Bare metal servers | Available. See Metal3 driver requirements. |
| KubeVirt | Virtual machines | Available. Native virtual machine provisioning. |
| BCM | Bare metal servers | Available for existing installations. |
| Terraform/OpenTofu | Infrastructure without a native driver | Available as a general-purpose option. |
| Cluster API | Infrastructure through a Cluster API provider's own contract | Available as a driver mechanism, not a specific provider. |
| NICo | Bare metal servers | In active development, not yet available. |
Physical drivers, such as Metal3 and BCM, provision bare metal directly with no hypervisor in the vMetal-managed path. KubeVirt provisions Kubernetes nodes as virtual machines on infrastructure you provide separately.
Each driver publishes its own requirements, capabilities, and day-two operations as they become available. This site currently documents the Metal3 driver in depth.
What vMetal provides, across drivers
Regardless of which driver provisions a Machine, vMetal gives you:
- Consistent provisioning — one Machine, NodeProvider, and NodeType model across every driver, so you request capacity the same way whatever sits underneath.
- Inventory and reclaim — vMetal tracks which servers are claimed and returns released ones to the pool, so a server serves many Machines over its life in the fleet.
- Tenant isolation — combine with vCluster and vNode for tenant isolation and secure runtime isolation on shared hardware.
Machines suit general compute, GPU and accelerator workloads, and other AI infrastructure. See GPU presentation modes for how vMetal exposes GPUs without owning the driver stack itself.