The recent walkthrough demonstrates that Metal3 can now drive the full lifecycle of KubeVirt virtual machines by routing its Ironic‑based bare‑metal operations through KubeVirtBMC. This "Metal3‑KubeVirtBMC integration" lets teams reuse existing bare‑metal provisioning pipelines for virtual workloads, reducing the need for separate test clusters and simplifying CI/CD for infrastructure‑heavy projects.
Why the Combination Matters
AI engineers often need reproducible hardware environments for model training or inference benchmarking. Cloud and platform engineers benefit from a single source of truth for both physical and virtual hosts, allowing consistent policy enforcement. DevOps and SRE practitioners can automate provisioning of test nodes without provisioning additional physical servers, while security engineers gain visibility into BMC traffic that now traverses the Kubernetes network, making it easier to audit and control.
Architecture Overview
The stack consists of four key pieces:
- KubeVirt – runs VMs as Kubernetes pods.
- KubeVirtBMC – exposes an IPMI/Redfish endpoint for each VM via a Service.
- Metal3 Bare Metal Operator (BMO) – creates
BareMetalHostresources that reference the virtual BMC. - Ironic Standalone Operator – provides the Ironic API that the BMO uses to power on/off hosts and attach boot media.
When Metal3 issues a power‑on request, Ironic sends a Redfish call to the virtual BMC Service. The BMC pod translates that call into a Kubernetes API operation that starts the corresponding KubeVirt VM. The flow is identical to a physical server, so no changes to Metal3 manifests are required.
Implementation Steps
All components are installed into a single Kubernetes cluster. The following abbreviated commands capture the essential workflow:
# Install cert‑manager (required for webhooks) helm upgrade --install cert-manager oci://quay.io/jetstack/charts/cert-manager \ --namespace cert-manager --create-namespace --set crds.enabled=true # Deploy KubeVirtBMC helm upgrade --install kubevirtbmc kubevirtbmc \ --repo=https://charts.kubevirtbmc.io \ --namespace kubevirtbmc-system --create-namespace # Create a PVC for the VM disk cat <After the BMC Service becomes ready (e.g.,
metal3-demo-vm-virtbmc.default.svc.cluster.local), aBareMetalHostcan be created that points to that address, and Metal3 will treat the VM exactly like a physical node.Operational and Security Considerations
Running a BMC inside the cluster introduces a new attack surface: the BMC Service is reachable via the cluster network, so RBAC and network policies should restrict access to the
virtualmachinebmcsresource and its Service. The secret that stores BMC credentials is a standard KubernetesSecret; ensure it is encrypted at rest and limited to the namespaces that require it. Because the VM’s MAC address is hard‑coded, MAC‑based boot filtering in Metal3 works without additional discovery steps, but any change to the VM definition must keep the address in sync.Cert‑manager supplies TLS certificates for both KubeVirtBMC and Metal3 webhooks. Operators should monitor the certificate renewal process to avoid webhook failures. Finally, because Ironic still expects IPMI/Redfish semantics, any deviation in the virtual BMC implementation could cause provisioning errors; testing with the same Redfish commands used for physical hardware is advisable before scaling.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Teams can now spin up fully‑featured bare‑metal test nodes on demand without allocating physical hardware, using the same Metal3 manifests they already maintain. The approach reuses existing CI pipelines, reduces infrastructure cost, and keeps security boundaries explicit through Kubernetes RBAC and network policies. Evaluate the fit for your environment by confirming that your Metal3 version supports virtual BMCs, that cert‑manager is operational, and that you have appropriate policies around the BMC Service and credential Secrets.
