Bring a lab up and tear it down
§ 1Purpose
The everyday lifecycle: validate, boot with provisions, inspect, stop.
§ 2Prerequisites
- A vmlab.wcl exists (found by walking up from cwd).
- Referenced templates are in the store or are pullable registry refs.
§ 3Flowchart
§ 4Steps
§ 4.11
§ 4.2Validate
$ vmlab validate
Always validate first
Schema + semantic checks with no side effects, including a full wscript type-check of every provision/handler. Run it after every edit.
Run vmlab validate. Fix any schema or semantic error before booting.
§ 4.32
§ 4.4Bring it up
$ vmlab up
Run vmlab up to create linked clones, boot the VMs and run provisions in declaration order. A provision failure fails the run. Pass VM names to bring up only a subset.
§ 4.53
§ 4.6Inspect
$ vmlab status
$ vmlab logs -f
vmlab status shows VM/segment state, IPs and ready flags. vmlab logs -f follows lab events; vmlab logs <vm> shows one VM's QEMU/serial output.
§ 4.74
§ 4.8Stop
$ vmlab down # graceful; clones retained
$ vmlab destroy # stop + DELETE clones and lab-local state
down vs destroy
down keeps the linked clones so you can resume. destroy deletes them and lab-local .vmlab/ state — only when you mean it.
Use vmlab down for a graceful stop that retains clones. Use vmlab destroy only to delete the clones and lab-local state entirely.
Verification
vmlab status reports the expected VM/segment states and ready flags; provisions completed without failing vmlab up.