# Using MicroVMs

link · 2026-06-30

> A VM that can reach the host's local network is a VM that can reach things it has no business reaching. So QEMU doesn't run in the host's network namespace at all. We `unshare` into fresh user, net and mount namespaces first. Inside that namespace a small wrapper bind-mounts a resolv.conf pointing at `127.0.0.1` so that QEMU's built-in slirp DNS isn't used, then installs blackhole routes for every special-use IP range (RFC 6890, so private networks, link-local, loopback, etc.) before it execs QEMU. `slirp4netns` then provides the namespace's outbound internet connection, with `--disable-host-loopback`, sandbox and seccomp all on. QEMU runs inside that namespace, and the guest's network card is attached to QEMU's own built-in user-mode networking. So every packet from the guest takes two hops: guest → QEMU's slirp → the namespace's `slirp4netns` → the internet. The guest never sees the host's network and the host's network never sees the guest. All of this is done without needing any privileges!

I've been reading a lot about microVMs and [Firecracker](https://firecracker-microvm.github.io/) lately as I work on async agent side project[^1] and I find it super interesting how people tackel the same UX problems (in this case: locking down the network).

[^1]: More on that soon hopefully.

[via Tangled's blog](https://blog.tangled.org/spindle-microvm/)