Product1 distinct publisher3 min readPublished
A CNCF walkthrough wires Metal3 to KubeVirtBMC so one BareMetalHost record can drive a virtual machine the same way it drives a server, which buys a single provisioning path at the price of a translator in the middle.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Someone had to type a MAC address by hand. The walkthrough pins the demo VM's interface to 02:00:00:00:00:01, because Metal3 wants a bootMACAddress on every BareMetalHost and it has to match a real NIC on the machine, so pinning it beats hunting down whatever random address KubeVirt would have generated [10]. That detail is the whole exercise in miniature. To make a VM legible to bare-metal tooling, you inherit the bookkeeping that bare metal comes with.
That indifference at the top of the stack is the actual product, and it has a price. The chain from a BareMetalHost record to a domain that changes power state is four handoffs long [1], for an operation kubectl performs in one call. Nothing gets thinner underneath, either. Both toolchains stay and a translator joins them: KubeVirt with a storage provider beneath it, cert-manager for webhook certificates, KubeVirtBMC itself, and Metal3 with Ironic inside it [2][6][7][13]. Five components to keep patched [3] so that one custom resource can mean either kind of machine.
The question worth settling before any of it goes in is who the caller is. If the thing asking for a machine already emits BareMetalHost objects, declaring a BMC address, credentials and a desired image [3], then handing a VM a virtual BMC is real consolidation. The caller keeps its interface, and it stops mattering whether the target has a chassis, because Metal3 only ever needed something that answers IPMI or Redfish [4]. If the caller is a script your own team owns, one that could talk to the KubeVirt API directly, then the emulated BMC is a costume, and you maintain it.
Here is what teams tell themselves in that second case: we standardised on one provisioning workflow. Here is what is actually running: an emulator translating Redfish into API calls against a control plane you already hold credentials for. The demo hints at the credential work that follows, too, with a Secret named demo-bmc-secret carrying the username admin and its password in stringData [14]. Fine for a blog post; a per-VM secret you will be minting in bulk if this becomes a fleet of simulated hosts.
The forcing question is short. Name the system that will read the BareMetalHost object. If you can name it and it is not you, this pairing removes a fork in your automation, and the four hops are the toll. If the answer is a pipeline you wrote and can change, the honest comparison is not Metal3 versus KubeVirt, it is one API call versus a translation layer with a certificate dependency [6] and a MAC address registry you now keep for machines that never had a NIC to begin with [10].
Ranked by verification strength, evidence, and original report placement.
Step 1 of the walkthrough installs cert-manager via helm, because both KubeVirtBMC and Metal3 components require cert-manager for webhook certificates.
Prerequisites listed are a Kubernetes cluster with virtualization support (nested virtualization or bare metal), KubeVirt installed and functional, a storage provider for VM disks, and kubectl, helm and kustomize installed locally; the post points readers to KubeVirt CI or Harvester for a cluster.
A CNCF blog post presents a complete end-to-end demo using Metal3 to manage and provision KubeVirt VMs through KubeVirtBMC, as if they were physical servers, written so readers can replicate every step.
Metal3 (Metal Kubed) is a CNCF Incubating project that brings bare-metal host management into the Kubernetes ecosystem and uses OpenStack Ironic under the hood to inspect hardware, set boot devices and write OS images to disks.
Metal3's core abstraction is the BareMetalHost custom resource: the user declares BMC address, credentials and desired image, and Metal3 handles the rest.
Metal3 expects to talk to a BMC via IPMI or Redfish; physical servers have these built in and KubeVirt VMs do not, unless KubeVirtBMC gives them one.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
product
The GPU fleet's utilisation now hinges on which tenants you dare pack together1 distinct publisher
product
Sovereignty audits are moving from the region picker to the plane topology1 distinct publisher
build
Kubernetes 1.35 lands 60 enhancements, 17 of them stable: treat the upgrade as a compatibility audit1 distinct publisher
product
Atlassian's automated RCA pitch is really an argument that manual root cause is a seniority tax1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable line by line, checked by nobody else
The strength here is unusual for a single-source story: the manifests, chart repository, namespace and resource sizes are all printed, so a reader with a cluster can falsify any of it in an afternoon. The weakness is equally plain — CNCF is the only voice, no one has published a replication, and the post contradicts itself on firmware, which is exactly the kind of slip that survives when no second pair of eyes runs the steps.
A chart to install, no installs to point to
What exists is packaging: a helm chart on a public repository, a controller-manager that comes up, Metal3 sitting at CNCF Incubating. What does not exist anywhere in this reporting is a user — no team, no CI system, no rack of simulated hosts anyone admits to running. The Metal3 side of the stack even has to be built from git main because a needed field had not shipped, which is a fair marker of how early this pairing is.
Sober post, one glossy phrase
Mostly this reporting says what it does and no more: it is called a demo, prerequisites are listed, tradeoffs like the pinned MAC are explained rather than hidden. The overclaim is the framing phrase — managing VMs 'just as if they were physical servers' — which quietly absorbs four handoffs, a shared failure domain and a git-main dependency into the word 'just'.
The foundation writing up its own shelf
CNCF is publishing about a project it hosts, in a series whose earlier installment introduced the other component being promoted, and the walkthrough routes readers to a specific chart repository and to Harvester for a cluster. None of that makes the commands wrong — they either work or they do not. It does mean nobody in this story had a reason to write the paragraph about when this approach is the wrong choice.
One post, one voice, one contradiction
Confidence is held down by breadth rather than quality. The technical detail is dense and self-consistent enough to act on, but everything rests on one publisher, the body we have is cut off partway through the Metal3 install step, and the firmware note argues with the manifest above it. Enough to try; not enough to quote as settled practice.