Hypervisor node bootstrapping simplification

Summary

Bootstrapping a hypervisor node today means aligning several independent artefacts:

• the OS image
• the provider image
• ignition
• kustomizations

Currently, we don't have a single artefact that describes "a node ready to host VMs." This roadmap item aims to make node bootstrapping simpler and more reliable by shipping more of the hypervisor stack in the OS image itself and streamlining the dependency chain between these artefacts.

The goal is to have a clear split:

• configuration lives in ignition
• everything else: the hypervisor stack and the ironcore providers in the OS image

This builds on the new ironcore-image format proposed in IronCore Image V2 (IEP).

---

Scope

In Scope

• OS Image with a preinstalled hypervisor stack (e.g. libvirt), building on the new ironcore-image format.
• Decision + evaluation on whether to bake ironcore providers into the OS image (e.g. libvirt-provider, dpservice, etc.).
• Reworking ignition and kustomizations so that ignition carries only configuration and the OS image carries everything else.

Out of Scope

• The new ironcore-image format itself, defined in IronCore Image V2 (IEP)
• The metaldata service design (tracked in IEP-18).
• Bare-metal provisioning / metal-operator changes beyond what bootstrapping
  requires.

---

Responsible Areas

• Metal Automation
• Virtualization
• Networking

---

Contributors

• @lukasfrank
• @gonzolino
• @friegger

---

Acceptance Criteria

• Operating System / OS Image

  • An OS image variant with a preinstalled hypervisor stack is published in
    os-images.

• Virtualization

  • Compute components (e.g. libvirt-provider and poollet) ship in the OS image.
  • libvirt-provider offers systemd units
  • provider exposes endpoints to "observe" it

• Networking

  • Networking components (e.g. dpservice / metalnet) ship in the OS image.

• Storage

  • Storage components (e.g. Ceph client / ceph-provider prerequisites) ship in the OS image.

• Common

  • Configuration is carried by ignition only; the rest ships in the OS image.

---

Action Items

• Assign labels (e.g., area/ironcore-api, kind/design)
• Set milestone (e.g., H1/2025)
• Assign dependent sub-issues in each required area
• Assign an owner to the issue using the GitHub "Assignee" field
• List all contributors in the "Contributors" section above
• Add this issue to the Roadmap project board

Start by reading the linked IronCore Image V2 proposal and inventorying the current OS image, ignition, and kustomization artifacts. Map the required hypervisor, provider, networking, and storage components to the acceptance criteria; done means an OS image is published with the required components and ignition carries only configuration.