2. React to lab events

on handlers: run a script when something happens instead of polling for it.

After this lesson you can

- Attach on "<event>" { run = … } handlers to a lab - Know the event families (vm.*, host.*) and their payloads - Test a handler with an ad-hoc vmlab script run

Before you start: Your first provision script

Where a provision runs once at boot, an on handler runs whenever its event fires for the lab's lifetime: on "vm.crashed" { run = "scripts/collect-dumps.ws" } reacts to a guest dying, on "host.disk_low" { run = "scripts/alert.ws" } to the host filling up. The handler script receives the event (VM name, details) alongside the lab handle.

For iterating on a script without bouncing the lab, vmlab script scripts/test.ws runs any wscript file against the running lab right now.

§ 1Exercise: Notice a crash

Add a vm.crashed handler that logs which VM died, then force-kill the guest's QEMU process to trigger it.

wscript
use vmlab

fn handle(event: Event, lab: Lab) {
    lab.log("handler: " + event.vm + " crashed — collecting nothing, just proving the wiring")
}

Expected result

Killing the VM's QEMU process makes the handler line appear in vmlab logs.

Hint

Handlers fire on *unexpected* exits — vmlab vm stop alp is a clean stop and won't trigger vm.crashed.