(Feb 2018)
systemd-nspawn utilizes the Linux kernel’s isolation features (cgroups, namespaces, etc.) to provide a “super-chroot” that isolates not only the filesystem, but also the network namespace, process tree, hostname, and IPC subsystems. The result is a light-weight container, similar to LXC (which uses the same kernel features) but less complex (or, arguably, less sophisticated).
The systemd-nspawn container must run with systemd as PID 1.
The containers have read-only access to a number of filesystems, such as /sys and /proc/sys.
See the systemd-nspawn(1) man page.
As of 2018, systemd-nspawn and its tooling feel fragile. I’m not sure it’s ready for production.
# debootstrap buster /var/lib/machines/mydebian http://ftp.us.debian.org/debian
# systemd-nspawn --directory=/var/lib/machines/mydebian passwd
By default, the container does have access to host network devices.
To completely isolate the container, use the --private-network option.
To join the container to the host’s bridge with a veth pair:
# systemd-nspawn --directory=/var/lib/machines/mydebian --network-bridge=br0
# machinectl list --all
# machinectl list-images
# machinectl start mydebian
# machinectl status mydebian
# machinectl login mydebian
# machinectl reboot mydebian
# machinectl poweroff mydebian
Dbus needs to be installed in the container for login to work:
# systemd-nspawn --directory=/var/lib/machines/mydebian apt-get install dbus
Read logs for the container:
# journalctl -M mydebian