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.
}
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.