Fleet KubeVirt platform

Experimental: optional spoke platform add-on (not a FleetApp). Validate on your hardware before production use.

Install Multus, CDI, and KubeVirt on a Ready workload cluster. Optionally attach VMs to the node LAN with a Multus bridge NAD (mgmt-l2).

Modes

Mode	Behavior
Pod network (default)	Multus + CDI + KubeVirt; VMs use masquerade / pod network
LAN L2	Host Linux bridge on every node + NAD `mgmt-l2` (default bridge `n0p0_mgmt_nw`). Prefer creating the bridge at bootstrap (`spec.providers.kubevirtBridge.enabled`); day-2 enable is supported

NAD IPAM is empty — LAN addresses come from site DHCP/static, not Kubernetes.

Operator path

Create cluster

Console Create cluster: enable KubeVirt (providers.install.kubevirt), optionally LAN Multus bridge (host bridge at bootstrap + NAD after install).

After Ready, the controller auto-queues the same install job when providers.install.kubevirt is set and the provider phase is still NotInstalled.

After Ready

Console Operations → Enable KubeVirt / Enable LAN Multus, or:

# KubeVirt only (pod-network VMs)
umkim cluster platform enable-kubevirt CLUSTER

# Install KubeVirt with LAN Multus, or add LAN Multus when KubeVirt is already Ready
umkim cluster platform enable-kubevirt CLUSTER --lan-bridge [--bridge n0p0_mgmt_nw]
umkim cluster platform enable-kubevirt CLUSTER --lan-bridge --wait 45m

umkim cluster platform status CLUSTER
umkim cluster candidates --require network.multus_l2

Day-2 --lan-bridge on an already-Ready KubeVirt cluster configures the host bridge on all nodes, installs the bridge CNI plugin, applies NAD default/mgmt-l2, and re-runs capability discovery (network.multus_l2). --force is only needed to re-run when LAN Multus is already enabled.

Jobs are mutually exclusive with node ops and storage configure. History type: configureKubevirt (on FleetClusterJoin.status.nodeOperationHistory).

k8s/helm providers.install flags and former service-provider APIs are not used (410 Gone); install Helm charts with FleetApp.

Virtual machine management

After KubeVirt is Ready on a cluster, operators manage guest VMs from the hub (no direct spoke kubeconfig required):

Surface	Path
Console	Clusters → cluster → Virtual machines
CLI	`umkim vm …`

Default console is serial. VNC opens on demand (websocket only while the modal/session is open). Power actions: soft/hard power off, soft/hard reboot, and power on.

umkim vm list --cluster CLUSTER
umkim vm get NAME --cluster CLUSTER [-n NAMESPACE]
umkim vm start|stop|restart NAME --cluster CLUSTER [--force]
umkim vm console NAME --cluster CLUSTER            # serial (TTY)
umkim vm console NAME --cluster CLUSTER --type vnc # binary VNC stream

See umkim CLI for full command reference.

Capabilities

Discovery sets:

Label	Meaning
`fleet.capability/kvm`	`/dev/kvm` present
`fleet.capability/kubevirt`	KubeVirt CR Available
`fleet.capability/network.multus_l2`	NAD `default/mgmt-l2` present

Filter Ready clusters with umkim cluster candidates --require kubevirt or --require network.multus_l2.

Rocky Linux 10 via Apps (`rocky-10-vm`)

Prefer the seeded Helm chart rocky-10-vm from Apps → Install chart (or FleetApp with short chart name rocky-10-vm). Configure cpu, memory, and disk.size in the install dialog / values. Requires KubeVirt + CDI and a storage class suitable for CDI imports (chart default local-path in charts/rocky-10-vm/values.yaml). Guest management after Ready uses the cluster Virtual machines page / umkim vm.

fleet-site — FCJ lifecycle and post-Ready operations
umkim CLI — platform and VM commands
GPU host prep — nested/GPU hosts

Full YAML samples and implementation notes live in the umkim repository docs/components/fleet-kubevirt.md.