nido-vm-testing

Nido VM Testing

Use Nido as a disposable VM lab for tests and agent workloads. Prefer real VMs when the result depends on system packages, init behavior, kernel isolation, networking, filesystem layout, OS services, or production-like assumptions that containers do not faithfully model.

Quick Start

Run the host preflight first:

nido doctor
nido images list

Minimal lifecycle:

cat > provision.sh <<'EOF'
#!/bin/sh
set -eux
apt-get update
apt-get install -y ca-certificates curl git make
EOF

nido spawn app-test --image ubuntu:24.04 --user-data provision.sh --port app:8080/tcp --memory 4096 --cpus 2 --json
nido info app-test --json
nido ssh app-test "echo ready"
nido delete app-test --json

For a ready automation example, run or adapt scripts/nido-ephemeral-test.sh.

Standard Workflow

1. Choose an image or template. Use cloud images for clean OS tests. Use templates when prerequisites are expensive and stable.
2. Write provisioning as a --user-data script. Install OS packages, users, services, certificates, language runtimes, and test dependencies here.
3. Spawn with explicit resources and port rules. Use --memory, --cpus, and --port label:guest/tcp; let Nido allocate host ports unless a fixed port is required.
4. Wait for SSH using nido info --json. Parse ssh_port and ssh_user; do not assume fixed ports.
5. Upload or fetch the software under test. Use direct ssh/scp with the port from nido info, or clone from an internal repository.
6. Run tests inside the VM. Keep commands non-interactive and capture logs/artifacts before cleanup.
7. Delete the VM. Use shell traps or CI cleanup steps. Avoid leaving stopped VMs unless debugging.

Best Practices

• Use unique names such as nido-ci-$RUN_ID and delete by exact name.
• Always parse nido info --json; ports are runtime allocations.
• Prefer auto host ports: --port api:8000/tcp. Fixed host ports are for human workflows, not parallel CI.
• Keep provisioning idempotent. A script should be safe if cloud-init retries it.
• Put slow, stable prerequisites into a template. Put changing app code into the ephemeral VM at test time.
• Pin OS images, package versions, and test commands for reproducibility.
• Keep secrets out of templates. Inject short-lived secrets at runtime and scrub logs.
• Use nido delete <name> for test cleanup. Avoid broad nido prune on shared developer machines.
• For Windows blueprints, use --gui on the first boot when diagnosing OOBE/post-install state.