Bare-metal without the Metal

COSCUP 2026

Transcript

1. Bare-metal without the Metal Emulating IPMI and Redfish for KubeVirt VMs Zespre Chang, 2026-08-09
2. About the Speakers • Zespre Chang 🇹🇼 • Staff Software Engineer at SUSE • Anish Bista 🇳🇵 • Kubernetes Engineer at KubeRox Technologies 2
3. Bare-metal Provisioning A bit of background • Lifecycle of a bare-metal server • A eet of bare-metal servers • Racking, cabling, and inspection • Remote management • Con guration and OS provisioning • Automation • Operation and maintenance • Scalability ➡Human-in-the-loop ➡Zero-touch fi fl 3
4. OS Provisioning Install OS on servers 1. *Turn on server 2. *Boot from the installation boot device 3. Start and complete the installation ow (interactive/automated) 4. *Reboot 5. *Boot from the OS installed device 6. Voilà! * requires physical access to the machine fl 4
5. 5 https://ageofnotes.com/wp-content/uploads/2023/10/Age-of-Empires-2-Cheats-Complete-Table.webp
6. BMC Always watching the system’s back • BMC (Baseboard Management Controller) • Dedicated processor • On server motherboard • Out-of-band control • Works without OS • Core capabilities • Power control • Boot options • Remote boot media • Console access • Firmware settings • Hardware monitoring 6
7. BMC Two ways to talk to the BMC • IPMI (Intelligent Platform Management • Red sh Interface) • HTTP + JSON • Binary over network • Modern REST model • Legacy, widely supported • Automation friendly • Direct control style fi 7
8. What’s Wrong with Bare-metal (Provisioning) Exactly? 8
9. “Bare-metal” Provisioning The bad and the ugly • Expensive • Low resource density • Slow in every single way (provisioning perspective) • System boot up • Your IT team 9
10. Entering the Virtualization Era 10
11. 11 https://ageofnotes.com/wp-content/uploads/2023/10/Age-of-Empires-2-Cheats-Complete-Table.webp
12. Virtualizing BMCs When your BMs become VMs • KVM and libvirt API • BMC emulators for VMs • Power a VM on/off is trivial • VirtualBMC: exposes IPMI ➡…but your provisioning stack can’t • sushy-tools: exposes Red sh talk libvirt API • Both assume libvirt/KVM domains ➡…But what if my VMs aren’t libvirt domains? fi 12
13. The Cloud-native Era 13
14. 14 https://ageofnotes.com/wp-content/uploads/2023/10/Age-of-Empires-2-Cheats-Complete-Table.webp
15. Containerizing BMCs When your VMs are in pods • KubeVirt • BMC emulators for KubeVirt VMs? • VMs run in pods, managed by Kubernetes • VirtualBMC & sushi-tools assume libvirt domains • A VM is a CR (VirtualMachine/ • They can’t reach VirtualMachine CR VirtualMachineInstance) inside a cluster • Power control is already Kubernetes-native ➡Gap: IPMI/Red sh on the front, KubeVirt API on the back fi 15
16. We Still Love You, Bare-metals fl 16 https://img ip.com/memetemplate/Epic-Handshake
17. Introducing KubeVirtBMC 17
18. KubeVirtBMC https://github.com/kubevirtbmc • Cloud-native BMC emulator • Protocol emulation interoperability layer • Red sh + IPMI on the front • KubeVirt API on the back • Comes with an Operator • Manage virtual BMCs as Kubernetes CRs fi 18
19. KubeVirtBMC https://github.com/kubevirtbmc • Provisioning stacks already speak IPMI/Red sh • Zero adaptation on the provisioner side • Metal3, Tinkerbell, Ironic, MAAS, Foreman… • The VM looks and behaves like bare metal • KubeVirtBMC exposes those same endpoints for • Behind the endpoints, it drives the KubeVirt API KubeVirt VMs • Power on/off/cycle —> start/stop the VM • Each VM gets its own BMC • Device boot order —> patch the VM CR • Each BMC has its own IP and credentials • Virtual media —> DataVolume + Hot-plug volume fi 19
20. KubeVirtBMC API spec and system architecture apiVersion: bmc.kubevit.io/v1beta1 kind: VirtualMachineBMC metadata: name: demo-bmc spec: authSecretRef: name: demo-bmc-credentials virtualMachineRef: name: demo-vm ipmi: enabled: true 20
21. Demo Time https://blog.zespre.com/metal3-meets-kubevirtbmc 21
22. Metal3’s VM Provisioning Flow Enabled by KubeVirtBMC With Redfish VirtualMedia 22
23. Project Trajectory A bit of story • Late 2023 • Project inception at HackWeek 23 • Initial operator and IPMI agent • Early 2024 • Project migration invited by KubeVirt representatives • Mid 2024 • Migration proposal accepted • Migration work began • Late 2024 • Early 2026 • Red sh agent • KubeVirt org adopted a different Red sh project • Early 2025 • Migration adopted as a KubeVirt GSoC project (co-mentored) • Mid 2025 • GSoC didn’t pan out; migration stalled fi fi (kubevirtbmc) • Now • Standalone • Real-world adoption, including Harvester • Late 2025 • Red sh VirtualMedia support 23 fi • Spun out into its own org • Actively growing
25. Future Work Driven by the community • Maturing Red sh implementation • Stateless vs. stateful • More endpoints supported • Today: a pure translator, holding no state • Conformance testing (DMTF Red sh Service • Async operations may force us to hold state Validator) • Open design question, not yet settled • Red sh Task API for asynchronous operations (e.g. • More ecosystem integration InsertMedia) • Metal3 use case demonstration and E2E testing (recently landed) • Validated against more provisioning stacks https://github.com/kubevirtbmc/kubevirtbmc/issues fi fi fi 25
26. Lessons from the Long Haul A bit of reflection • Putting it out there • Use cases users applying it in ways you didn’t design for • Promoting the project (blog articles, talks, social • RFEs: the roadmap the community writes for media posts, etc.) you • Reaching potential users where they already are • Where it’s heading • What came back • Project directions shaped by real usage • Feedback from people actually running it • Helping hands: the project has outgrown one • Bugs you only nd in someone else’s cluster maintainer fi 26
27. Thank you! 27