Run vmlab in a container

§ 1Purpose

Run a lab inside Docker/Podman with KVM and optional eBPF network acceleration.

§ 2Prerequisites

§ 3Flowchart

1. Build (or pull) the image2. Run a lab

§ 4Steps

§ 4.11

§ 4.2Build (or pull) the image

console
$ docker build -t vmlab -f Containerfile .   # from the repo (or: just image)
$ docker pull ghcr.io/<owner>/vmlab:latest   # or a published release

Build context

WCL and wscript are git dependencies (fetched during the build), so the context is just the vmlab repo. The image bundles the vmlab CLI and the vmlab-web UI server.

Build with just image (or the command above), or skip building — every release is published to GHCR as ghcr.io/<owner>/vmlab:<version> (and :latest).

§ 4.32

§ 4.4Run a lab

console
$ docker run --rm -it --device /dev/kvm --device /dev/net/tun \
    --cap-add BPF --cap-add NET_ADMIN -e VMLAB_FASTPATH=auto \
    -v ~/.local/share/vmlab/templates:/root/.local/share/vmlab/templates \
    -v "$PWD":/lab -w /lab vmlab vmlab up

Least privilege

No --privileged or host network mode. The eBPF path receives only /dev/net/tun, CAP_BPF, and CAP_NET_ADMIN; it falls back to userspace when unavailable.

Mount the template store (persistent) and the lab directory, grant /dev/kvm, and add /dev/net/tun plus CAP_BPF and CAP_NET_ADMIN when eBPF acceleration is wanted. Run a vmlab verb (the command above overrides the default). By default the container serves the web console (vmlab-web on :7878 — see the docker compose stack); for CLI use, override the command or drive a running container via docker exec <ctr> vmlab ....

Verification

vmlab status (via docker exec or in the one-shot command) reports the lab running; no KVM-fallback warning appears in the logs.