IPMI Guide¶

This guide covers using IPMI (Intelligent Platform Management Interface) with KubeVirtBMC for out-of-band management of virtual machines.

Overview¶

IPMI is a standardized UDP-based protocol for chassis control. KubeVirtBMC implements IPMI chassis commands for power management and boot device configuration.

Service Endpoint:

<vm-name>-virtbmc.<namespace>.svc.cluster.local:623

spec:
  ipmi:
    enabled: true

Accessing IPMI¶

Run IPMI Client in Pod (Recommended)¶

Since IPMI uses UDP and requires cluster network access, run an IPMI client pod:

kubectl run ipmitool \
    --image=kubevirtbmc/ipmitool \
    --restart=Never \
    --command -- sleep 9999999

kubectl exec -it ipmitool -- /bin/sh

Inside the pod, set environment variables for reuse:

export USERNAME="admin"
export PASSWORD="admin123"
export HOSTNAME="testvm-virtbmc.default.svc.cluster.local"  # <vmbmc-svc-name>.<namespace>.svc.cluster.local

Then use the environment variables in all ipmitool commands:

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" <command>

Delete the pod when done:

kubectl delete pods ipmitool

Power Management¶

Power Status¶

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" power status

Output:¶

• Chassis Power is on - VM is running
• Chassis Power is off - VM is stopped

Power On¶

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" power on

Power Off (Forceful)¶

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" power off

Immediate power down without OS notification.

Power Off (Graceful / ACPI Soft Shutdown)¶

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" power soft

Sends ACPI shutdown request to the guest OS for a graceful stop. Requires ACPI support in the guest.

Power Cycle¶

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" power cycle

Forces the VM to power off then immediately power back on.

Hard Reset¶

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" power reset

Forcefully resets the VM without cutting power, keeping it running.

Power Commands Summary¶

Transitional VM State Handling (IPMI Retry Signal)¶

When KubeVirt is between asynchronous lifecycle steps (e.g., the VM/VMI is still starting or stopping), virtbmc must not treat those transitional windows as guaranteed success.

Current behavior:

• The agent uses a Try-Then-Verify approach to avoid swallowing ambiguous “already running/already stopped” situations.
• If the VM is still transitional and the requested operation is not yet reflected in the final VM power state, virtbmc returns a retryable IPMI error:
• Completion code: Node Busy (0xC0)

Clients that implement “retry on Node Busy” (notably Ironic) can re-issue the power action until the VM state converges.

Boot Device Configuration¶

Set Boot to PXE¶

# One-shot (default)
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev pxe

# Persistent
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev pxe options=persistent

# One-shot + UEFI
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev pxe options=efiboot

# Persistent + UEFI
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev pxe options=persistent,efiboot

Set Boot to Disk¶

# One-shot (default)
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev disk

# Persistent
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev disk options=persistent

# One-shot + UEFI
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev disk options=efiboot

# Persistent + UEFI
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev disk options=persistent,efiboot

Set Boot to CD-ROM¶

# One-shot (default)
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev cdrom

# Persistent
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev cdrom options=persistent

# One-shot + UEFI
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev cdrom options=efiboot

# Persistent + UEFI
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev cdrom options=persistent,efiboot

Supported Boot Devices¶

Boot Options¶

chassis bootdev supports the following options= flags:

Multiple options can be combined with commas, e.g. options=persistent,efiboot.

# data byte 1: 0xe0 = boot flags valid + persistent + EFI (use 0xa0 for one-shot + EFI)
# data byte 2: boot device selector — pxe=0x04, disk=0x08, cdrom=0x14
ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" raw 0x00 0x08 0x05 0xe0 0x04 0x00 0x00 0x00

Read Back Boot Flags¶

chassis bootparam get 5 (Get System Boot Options, boot flags parameter — see Table 28-14 "Boot Option Parameters" in the IPMI v2.0 specification) reads back the current boot device override:

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootparam get 5

This produces output similar to:

Boot parameter version: 1
Boot parameter 5 is valid/unlocked
Boot parameter data: 8000040000
 Boot Flags :
   - Boot Flag Valid
   - Options apply to only next boot
   - BIOS PC Compatible (legacy) boot
   - Force PXE

Clear Boot Override¶

Clear any pending boot device override and restore the VM's default boot order:

ipmitool -I lanplus -U "$USERNAME" -P "$PASSWORD" -H "$HOSTNAME" chassis bootdev none

One-Shot Boot and In-Guest Reboot¶

When using one-shot boot override (the default without options=persistent), the VM boots from the specified device once, then KubeVirtBMC restores the VM's default boot order. This restore is tied to VMI recreation: by default, an in-guest reboot restarts the guest inside the existing VirtualMachineInstance (VMI), which keeps the boot order it was created with. So if the guest OS reboots itself (e.g., after completing an OS installation), the VM boots from the override device again instead of the default boot order — and a one-shot override set on a running VM is ignored entirely by an in-guest reboot, since it only exists in the VM template.

Setting the KubeVirt VirtualMachine's rebootPolicy to Terminate makes guest reboots terminate the VMI, so the VM controller recreates it from the current template and in-guest reboots behave the same as BMC-initiated power actions.

Next Steps¶

• Read the Redfish Guide for RESTful API access