A fleet of VMs, two in a boot loop, and no way to see it from the host
Fifty Debian VMs on a Proxmox cluster, each with OVMF firmware. Yesterday two of them rebooted into a kernel that panics. In GRUB-land the VM is up from the hypervisor's view, SSH gets no answer because the kernel panicked before the network came up, and you open consoles one VM at a time to find out which are broken. LamBoot answers the question from the host, before you open a single console.
How LamBoot answers it, with no agent inside the guest
1. LamBoot writes its boot health to UEFI variables
Under its vendor GUID: LamBootState (0 Fresh, 1 Booting, 2 BootedOK, 3 CrashLoop), LamBootCrashCount, LamBootLastEntry, LamBootTimestamp, and LamBootVersion.
2. The host reads those variables from the VM's OVMF_VARS
lamboot-pve-monitor on the Proxmox host reads the per-VM OVMF_VARS_<vmid>.fd file and emits a JSON boot-health record per VM. Nothing runs inside the guest: no agent, no SSH, no guest cooperation.
3. Identity flows the other way, through QEMU fw_cfg
The host writes /var/lib/lamboot/<vmid>.json and exposes it to the guest as opt/lamboot/config. LamBoot reads it at startup and learns its own VMID, fleet ID, and role. This is configured through /etc/lamboot/fleet.toml (a [fleet].id and a [roles] VMID-to-role map) and a Proxmox hookscript.
Proxmox host Guest VM (OVMF firmware) ┌───────────────────────┐ ┌──────────────────────────┐ │ lamboot-pve-monitor │ boot health │ LamBoot (early boot) │ │ reads OVMF_VARS_*.fd │ ◀────────────── │ writes NVRAM vars │ │ decodes LamBoot vars │ │ LamBootState, Crash... │ │ outputs table / JSON │ │ │ │ │ identity │ │ │ /var/lib/lamboot/ │ ──────────────▶ │ reads opt/lamboot/ │ │ <vmid>.json (fw_cfg) │ │ config: vmid/fleet/role │ └───────────────────────┘ └──────────────────────────┘
What the host reads
LamBoot vendor GUID: 4C414D42-4F4F-5400-0000-000000000001
| Variable | Type | Purpose |
|---|---|---|
| LamBootState | u8 | 0=Fresh, 1=Booting, 2=BootedOK, 3=CrashLoop |
| LamBootCrashCount | u8 | Crash counter, resets on a successful boot |
| LamBootLastEntry | UTF-8 | ID of the last booted entry |
| LamBootTimestamp | 8 bytes | Packed UTC y/m/d/h/m/s |
| LamBootVersion | u32 | Packed major.minor.patch |
Running the monitor
# One-shot: show the current state of every LamBoot VM
sudo lamboot-pve-monitor
# JSON output for pipelines
sudo lamboot-pve-monitor --json
# Filter to a specific VM
sudo lamboot-pve-monitor --vmid 100
# Watch mode with webhook alerts on CrashLoop
sudo lamboot-pve-monitor --watch --webhook https://hooks.slack.com/services/...
The monitor reads the NVRAM block out of each VM's OVMF_VARS_<vmid>.fd file on the host. It requires no VM agent and no guest access.
Zero-touch Secure Boot for VM fleets
Pre-enrolled OVMF_VARS so cloned VMs boot LamBoot under Secure Boot with no MokManager step. Apply LamBoot's enrolled OVMF_VARS_lamboot.fd to one VM, install with --signed --no-mok, then convert it to a template. Clones inherit the trust state.
See the Security page for Config 4 in the context of all four configurations, and the Install page for the OVMF_VARS flow. The full host-side procedure is in the Proxmox operations docs.
The host-side toolkit builds on this
lamboot-tools is the Linux UEFI boot toolkit, a separate product in the LamBoot family. It builds on the host-side primitives here for fleet operations, including a Proxmox VE companion. The Tools page covers it.