A whirlwind tour of systemd-nspawn containers

In the last yearly update, I talked about isolating my self-hosted LLMs
working in Ollama in addition to Open WebUI in
systemd-nspawn containers and promised a weblog publish about it. However, whereas
writing that weblog publish, a footnote on why I’m utilizing it as a substitute of Docker
by accident changed into a full blog post on its own. Here’s the precise
publish on systemd-nspawn.

Fundamentally, systemd-nspawn is a light-weight Linux namespaces-based
container know-how, not dissimilar to Docker. The distinction is
largely in picture administration—as a substitute of describing the way to construct pictures with
Dockerfiles and distributing prebuilt, read-only pictures containing
ready-to-run software program, systemd-nspawn is often used with a writable root
filesystem, functioning extra equally to a digital machine. For these of you
who keep in mind utilizing chroot to run software program on a unique Linux
distro, it will also be described as chroot on steroids.

I discover systemd-nspawn particularly helpful within the following eventualities:

1. When you need to run some software program with some extent of isolation on a VPS,
   the place you’ll be able to’t create a full digital machine attributable to nested virtualization
   not being obtainable¹;
2. When it’s worthwhile to share entry to {hardware}, resembling a GPU (which is why I run
   LLMs in systemd-nspawn);
3. When you don’t need the overhead of virtualization;
4. When you need to immediately entry some information on the host system with out
   resorting to virtiofs; and
5. When you’ll usually use Docker however can’t or don’t need to. For causes,
   please see the footnote-turned-blog post.

In this publish, I’ll describe the method of establishing systemd-nspawn
containers and the way to use them in some widespread eventualities.

Update (2025-05-19):
added safer Alpine container creation instructions
and some more guidance on establishing Alpine Linux
containers.

Start with a chroot

systemd-nspawn, like all containers, requires a separate rootfs in a
listing. Since it doesn’t include a picture supervisor to construct pictures for you,
you’ll want to make use of the normal Unix method of making a chroot. It is,
in spite of everything,
chroot on steroids.

For systemd-nspawn, the everyday conference is to place these rootfses below
/var/lib/machines/[hostname], the place the hostname is that of the container. For
this train, I’ll simply use the title of the OS because the hostname.

Each Linux distro has its personal means of making a brand new rootfs, so we’ll undergo
among the extra widespread ones. I’m testing all this on Debian, however there’s no
purpose why you wouldn’t be capable to do any of this on one other distro by
substituting the equal packages. Still, I’ll in all probability go deeper into Debian
as a result of I’m extra aware of it.

debootstrap on the Debian household

debootstrap has featured on this weblog many instances, largely when
doing loopy issues like installing Debian by hand from rescue systems.
For Debian-based distros like Ubuntu or Debian itself, that is the instrument to make use of
to create a rootfs.

On a Debian-based OS, set up it with sudo apt set up debootstrap. It could
even be packaged on different distros, or you’ll be able to simply obtain it from Debian’s
repositories:

$ curl -L https://salsa.debian.org/installer-team/debootstrap/-/archive/master/debootstrap-master.tar.gz | tar xz
...
$ cd debootstrap-master/
$ ./debootstrap 
I: utilization: [OPTION]...   [ [

Either way you installed debootstrap, let’s create the rootfs in
/var/lib/machines/debian:

$ sudo debootstrap --include=systemd,dbus,locales,bash-completion,curl bookworm /var/lib/machines/debian
I: Target architecture can be executed
I: Retrieving InRelease 
...
I: Base system installed successfully.

Here, we’ve installed bookworm, but feel free to substitute this for the
latest Debian release. To avoid silly issues, I ensured that systemd and
dbus are installed, along with locales to avoid weird warnings in apt,
bash-completion so I don’t hate my life when typing in commands by hand, and
curl so you can download stuff later. Some of these require a bit of
additional configuration later, which we’ll do once we boot into the container.

Installing RHEL-derivatives with dnf

First, install dnf and rpm if you are on another distro, e.g. on Debian:

$ sudo apt install dnf rpm
...
Setting up dnf (4.14.0-3+deb12u1) ...
Setting up rpm (4.18.0+dfsg-1+deb12u1) ...
...
$ sudo mkdir -p /var/lib/rpm
$ sudo rpm --initdb

Then, we make a Fedora 41 chroot as an example:

$ sudo mkdir -p /var/lib/machines/fedora/etc/dnf
$ sudo tee /var/lib/machines/fedora/etc/dnf/dnf.conf > /dev/null
[fedora]
title=Fedora $releasever - $basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
gpgkey=https://getfedora.org/static/fedora.gpg

[updates]
title=Fedora $releasever - $basearch - Updates
metalink=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
gpgkey=https://getfedora.org/static/fedora.gpg
$ sudo dnf --releasever=41 --best --setopt=install_weak_deps=False --repo=fedora --repo=updates --installroot=/var/lib/machines/fedora set up dnf fedora-release glibc glibc-langpack-en iproute iputils much less ncurses passwd systemd systemd-networkd systemd-resolved util-linux vim-default-editor
...
Transaction Summary
================================================================================
Install  137 Packages

Total obtain measurement: 62 M
Installed measurement: 206 M
Is this okay [y/N]: y
...
Complete!

Installing Alpine Linux with alpine-nspawn-install

Alpine Linux is usually utilized in Docker pictures attributable to its light-weight measurement, so I
thought I would as effectively attempt creating an Alpine Linux chroot. The traditional instrument for
this form of factor is alpine-chroot-install, however its default behaviour
is horrifying for our use case. For instance:

1. If the present listing is inside /house, it binds it into the chroot it
   configures for “compatibility causes,” with none warning. I virtually
   by accident deleted my whole house listing when working rm -rf on
   the chroot…
2. It mounts /dev, /proc, and /sys into the chroot as effectively. In the case of
   /dev, any subsequent try and chown the container to reap the benefits of
   UID isolation would chown all of the gadgets on the host system as effectively,
   resulting in a catastrophe that thankfully may very well be fastened by rebooting.

It is feasible to run a loopy umount command afterward to scrub up after
alpine-chroot-install, resembling:

mount | grep /var/lib/machines/alpine | reduce -d' ' -f3 | type -r | whereas learn -r path; do sudo umount "$path"; achieved

However, I deem this a ticking time-bomb ready to blow up in somebody’s face,
so as a substitute, I forked the script and created alpine-nspawn-install.
My model removes all of the loopy “options” of alpine-chroot-install that
don’t make sense for systemd-nspawn, e.g. the mounting, chroot helper scripts,
qemu assist, and so on.², whereas putting in a extra sane listing of
packages by default. You can use it like this:

$ wget https://raw.githubusercontent.com/quantum5/alpine-nspawn-install/refs/heads/master/alpine-nspawn-install
...

2025-05-19 22:23:27 (47.6 MB/s) - ‘alpine-nspawn-install’ saved [15897/15897]
$ sudo bash alpine-nspawn-install -d /var/lib/machines/alpine
...
---
Alpine container set up is full.

Now let’s see if Alpine lives as much as its popularity:

$ sudo du -sh /var/lib/machines/debian
338M	/var/lib/machines/debian
$ sudo du -sh /var/lib/machines/fedora
507M	/var/lib/machines/fedora
$ sudo du -sh /var/lib/machines/alpine
16M	/var/lib/machines/alpine

Well, that’s definitely spectacular… Alpine is an order of magnitude smaller
than the opposite two, whereas Fedora is kind of bloated with the listing of packages I
have put in. I’m not a Fedora person and copied the bundle listing from
the Arch Linux wiki guide on systemd-nspawn, so I’m not certain if it’s
as a result of I’ve put in bloat, however all of them appear fairly obligatory… It’s
definitely larger than what dnf claimed to be, so I took a glance, and dnf
created 260 MiB of stuff below /var/cache/dnf.

Also to be truthful to Debian, I did set up a bunch of “bloat” like locales for a
extra nice expertise. Removing the “bloat” ends in 305 MiB, which is
barely smaller.

Initial boot with systemd-nspawn

First, set up systemd-nspawn with sudo apt set up systemd-container or
your distro’s equal.

Then, you will get a root shell in a container by working the next command:

$ sudo systemd-nspawn -D /var/lib/machines/[name] -M [name] --private-users=decide --private-users-ownership=chown

And here’s what every argument does:

• -D (--directory) specifies the listing of the rootfs;
• -M (--machine) specifies the machine title, which can be set because the
  hostname contained in the container;
• --private-users=decide permits UID and GID namespaces by choosing a spread of
  65536 UIDs and GIDs from an unused block on the host system ranging from a
  a number of of 65536 within the vary of 524288 and 1878982656³. Alternative
  choices embrace sure, which selects the vary ranging from the proudly owning UID
  and GID of the rootfs (should be a a number of of 65536); no, which disables UID
  namespacing; an integer, which serves as beginning UID for a block of 65536; or
  a string of the format a:b, the place a is the beginning UID and the variety of
  UIDs to assign to the container; and eventually
• --private-users-ownership=chown modifications the possession of the rootfs to that
  of the UID and GID chosen in order that on future boots, --private-users=sure will
  hold utilizing the identical UIDs and GIDs.

Let’s boot Debian for example:

$ sudo systemd-nspawn -D /var/lib/machines/debian -M debian --private-users=decide --private-users-ownership=chown
Spawning container debian on /var/lib/machines/debian.
Press ^] thrice inside 1s to kill container.
Selected person namespace base 1766326272 and vary 65536.
root@debian:~#

And we’re within the newly created Debian container. Note that that is simply a
root shell and isn’t a correct approach to deploy the container long run. There isn’t any
init course of even.

Debian-specific setup suggestions

If you will be utilizing a root shell for a big period of time and
need autocomplete to keep away from typing whole instructions:

root@debian:~# cp /and so on/skel/.bashrc .
root@debian:~# . ~/.bashrc

If you’re simply utilizing the container to run a single utility, it could possibly get
actually tedious to handle your personal customers after which sudo, so I simply choose to do the
administration as root and having a functioning .bashrc works wonders. This is
technically not finest observe, however I mainly by no means run instructions in single
utility containers that don’t require root anyway, so it makes no actual
distinction.

debootstrap additionally copied the host’s hostname into /and so on/hostname. Let’s repair
that:

root@debian:~# hostname > /and so on/hostname

Getting again into the container

If you exited the basis shell for some purpose, you’ll be able to return by doing:

$ sudo systemd-nspawn -D /var/lib/machines/debian -M debian --private-users=sure
Spawning container debian on /var/lib/machines/debian.
Press ^] thrice inside 1s to kill container.
Selected person namespace base 1766326272 and vary 65536.
root@debian:~#

Preparing the container

Running the container like this isn’t a long-term resolution. You in all probability need to
set it as much as run correctly within the background. However, this leaves the query
of the way to entry the container. If you’re utilizing a systemd-based distro, you
have a couple of choices:

• If you simply need to entry the container from the host machine, you don’t want
  to do something, as you’ll see the way to get direct shell entry with
  machinectl. You also can:
• Set a root password with passwd so you’ll be able to log in from a terminal:

  root@debian:~# passwd
  New password:
  Retype new password:
  passwd: password up to date efficiently
  

• Install openssh-server and arrange SSH keys to attach remotely (you’ll additionally
  have to arrange networking, as defined later, otherwise you gained’t be capable to
  join):

  root@debian:~# apt set up openssh-server
  ...
  Created symlink /and so on/systemd/system/sshd.service → /lib/systemd/system/ssh.service.
  Created symlink /and so on/systemd/system/multi-user.goal.desires/ssh.service → /lib/systemd/system/ssh.service.
  Processing triggers for libc-bin (2.36-9+deb12u10) ...
  root@debian:~# curl -q https://ssh.qt.ax -o ~/.ssh/authorized_keys
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  100   243  100   243    0     0   3934      0 --:--:-- --:--:-- --:--:--  3983
  

  Note that as a result of we solely have a root shell proper now, not a correct boot,
  systemd (or every other init system) isn’t really working—so don’t count on to
  be capable to begin sshd for the second. The subsequent step will boot the container
  correctly.

• Create a person, arrange sudo, and so on. and log in as that person. This is left as an
  train for the reader.

Note that console and shell entry by way of machinectl requires systemd to be
working inside a container. This won’t be attainable when utilizing a non-systemd
distro, resembling Alpine. If you’re utilizing Alpine, you’ll want the
openssh-server route.

Alpine Linux notes

The default Alpine Linux set up created by alpine-chroot-install is
configured solely for chroot use and doesn’t even embrace a functioning
init system. To run it in a systemd-nspawn container correctly, we’ll have to
set up openrc, their init system, in addition to openssh-server:

alpine:~# apk add openrc openssh-server
...
alpine:~# rc-update add sshd
alpine:~# rc-update add networking

If you’re utilizing my alpine-nspawn-install script as a substitute, that is all
achieved for you. All you must do is a few fundamental configuration:

alpine:~# hostname > /and so on/hostname
alpine:~# mkdir -p ~/.ssh
alpine:~# wget https://ssh.qt.ax -O ~/.ssh/authorized_keys
...

Alpine makes use of ifupdown-ng to configure networking, and the syntax ought to be
appropriate with Debian’s, so you’ll be able to simply copy the examples under. You’ll want
to do the networking configuration earlier than beginning the container, or you may be
unable to log in by way of ssh.

Using machinectl

We can create /and so on/systemd/nspawn/[name].nspawn to handle the container with
machinectl, e.g. machinectl begin [name]. Note that the
/and so on/systemd/nspawn listing isn’t created by default, so chances are you’ll have to:

$ sudo mkdir -p /and so on/systemd/nspawn

The .nspawn file is a textual content file in INI format that accommodates the equal of
command line arguments to systemd-nspawn. For the fundamentals, do the equal of
--private-users=sure:

There are many different choices, resembling networking, useful resource limits, and bind
mounting directories on the host system into the container. We’ll cowl these
later.

For non-systemd distros like Alpine, add KillSignal=SIGTERM to the [Exec]
part to make sure that init can terminate correctly when the container is
stopped. The default sign of SIGRTMIN+3 is barely understood by systemd, and
SIGTERM is known extra broadly.

For now, let’s attempt beginning the container within the background, with a full init
system:

$ sudo tee /and so on/systemd/nspawn/debian.nspawn > /dev/null
[Exec]
Non-publicUsers=sure
$ sudo machinectl begin debian
$ sudo machinectl login debian
Connected to machine debian. Press ^] thrice inside 1s to exit session.

Debian GNU/Linux 12 debian pts/1

debian login: root
Password: 
Linux debian 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64

The packages included with the Debian GNU/Linux system are free software program;
the precise distribution phrases for every program are described within the
particular person information in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by relevant legislation.
Last login: Wed Mar 19 22:59:57 EDT 2025 on pts/1
root@debian:~#

And we’re logged in! To depart, press Ctrl+] thrice
to disconnect from the console, like machinectl suggests.

You also can simply get a direct shell with machinectl shell:

$ sudo machinectl shell root@debian
Connected to machine debian. Press ^] thrice inside 1s to exit session.
root@debian:~#

To cease this container, use sudo machinectl cease. For non-systemd distros, use
sudo systemctl cease systemd-nspawn@[name].

To run this container on boot, you’ll be able to merely run:

$ sudo machinectl allow debian

To undo this, use sudo machinectl disable.

Note that machinectl simply controls the underlying systemd unit,
systemd-nspawn@[name].service. This will change into necessary later. Note that you simply
can configure further choices on the unit by working
sudo systemd edit systemd-nspawn@[name].service.

Networking

Networking is configured below the [Network] part within the .nspawn file.
There are a number of choices:

Use host networking

This signifies that the container shares the identical community because the host machine. There
isn’t any community isolation anyplace. This is the best choice to arrange, but it surely’s
not very remoted, so I wouldn’t advocate it if you’d like isolation.

This is the default with invoking systemd-nspawn immediately, which is why
apt set up labored earlier with none networking config. This might be enabled
with VirtualEthernet=no within the .nspawn.

Use a bridge

A Linux bridge is mainly only a digital ethernet change. On Debian, you’ll be able to
create one with ifupdown by putting in the bridge-utils packages and
modifying your /and so on/community/interfaces.

If you’re working a PC behind a router at house (or by some means have plenty of IPs
out of your internet hosting supplier), you’ll be able to add your present interface (we’ll use
eth0 for example) to a bridge. It’ll be like connecting each the cable that
goes into eth0 and your PC right into a digital change, together with any containers.
You’ll want to copy the IP project at present on eth0 onto the bridge,
because it successfully pulls eth0 out of your machine. Your IP configuration
will must be achieved on the bridge interface as a substitute, which connects to the
digital port on the change on your machine.

For static IPs, add the next stanza to /and so on/community/interfaces and
delete (or remark out with #) the block for eth0:

auto br_test
iface br_test inet static
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
    tackle 192.0.2.123/24 # change this with the present eth0 IPv4 tackle
    gateway 192.0.2.1      # change this with the present eth0 IPv4 gateway

# take away this complete part if you do not have IPv6
iface br_test inet6 static
    tackle 2001:db8::123/64 # change this with the present eth0 IPv6 tackle
    gateway 2001:db8::1      # change this with the present eth0 IPv6 gateway

Alternatively, in case you want DHCP for IPv4 and SLAAC for IPv6:

auto br_test
iface br_test inet dhcp
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0

iface br_test inet6 auto

You can after all title the bridge something you’d like, although you’re suggested to
begin the title with br. Also notice that this turns off
the Spanning Tree Protocol (STP) to make new connections go surfing
quicker, however you actually shouldn’t be involving this digital bridge in a loop
topology anyway. Doing bridges on every other platform or networking instrument is left
as an train for the reader. The Arch Linux wiki could show
useful right here even in case you aren’t utilizing Arch Linux.

Then, you’ll be able to simply use Bridge=br_test in your .nspawn file
(--network-bridge=br_test on the command line) to hook up the digital
interface host0 contained in the container to the bridge. You can then arrange
/and so on/community/interfaces contained in the container (or your distro’s equal) as
follows:

auto host0
iface host0 inet static
    tackle 192.0.2.124/24 # change this with an unused IP tackle on the community
    gateway 192.0.2.1      # change this with the present eth0 IPv4 gateway

# take away this complete part if you do not have IPv6
iface host0 inet6 static
    tackle 2001:db8::123/64 # change this with an unused IP tackle on the community
    gateway 2001:db8::1      # change this with the present eth0 IPv6 gateway

Alternatively, in case you want DHCP for IPv4 and SLAAC for IPv6:

auto host0
iface host0 inet dhcp
iface host0 inet6 auto

Note which you could hook up a number of containers to the identical bridge, so that you solely
have to do that as soon as.

If you’re utilizing systemd-networkd within the visitor, create
/and so on/systemd/community/host0.community with the next content material within the
container:

[Match]
Name=host0

[Link]
RequiredForOnline=routable

[Network]
# for DHCP
DHCP=sure
# or remark it out and use static IPs:
Address=192.0.2.124/24
Gateway=192.0.2.1
Address=2001:db8::123/64
Gateway=2001:db8::1

You could have to allow systemd-networkd:

[root@fedora ~]# systemctl allow --now systemd-networkd

Use NAT

Alternatively, in case you can’t bridge your present community (e.g. you’re utilizing a
VPS and solely have one IP assigned), all is just not misplaced. You can create a bridge
with your personal customized community and route it as a substitute. This is bridge is new digital
community and the true community interface isn’t plugged into it.

For IPv4, I’d advocate allocating your self a random /24 from
the RFC 1918 vary. We’ll use 192.0.2.0/24 as the instance, since
it’s reserved for documentation.

For IPv6, ask your ISP to delegate you a /64 (or an even bigger block, however you solely
want a /64 for this), which most competent⁴ VPS suppliers ought to be
in a position to do. If you’re working this at house, see in case your router can use DHCP-PD
to request a big block and delegate a /64 to the host machine. We’ll use
2001:db8::/64 as the instance.

In both case, assign the primary tackle within the subnet to the bridge per
conference.

auto br_test
iface br_test inet static
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    tackle 192.0.2.1/24

# take away this if you cannot get a IPv6 block
iface br_test inet6 static
    tackle 2001:db8::1/64

You’ll then have to arrange NAT by working the next iptables command:

$ sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -j MASQUERADE

Alternatively, in case you have a static IP on the host, say 198.51.100.123, you
also can use a SNAT rule, which is quicker:

$ sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -j SNAT --to-source 198.51.100.123

You’ll have to run this each boot. Doing so is left as an train for the
reader. You can use one of many prebuilt firewalls, a systemd unit, and even
rc.native. For extra particulars, seek the advice of your distro’s documentation on iptables.

You’ll additionally have to configure the next sysctls. You can achieve this by including
them into /and so on/sysctl.conf or uncommenting the road that already exists:

web.ipv4.ip_forward=1
web.ipv6.conf.all.forwarding=1

Then run sudo sysctl -p. This will permit the host machine to behave as a router.

Once that’s achieved, use Bridge=br_test in your .nspawn file like earlier than to
hook up host0 contained in the container to the bridge. You can then arrange
/and so on/community/interfaces contained in the container (or your distro’s equal) as
follows:

auto host0
iface host0 inet static
    tackle 192.0.2.2/24 # change this with an tackle not already in use 
    gateway 192.0.2.1

# take away this complete part if you do not have IPv6
iface host0 inet6 static
    tackle 2001:db8::2/64 # change this with an tackle not already in use
    gateway 2001:db8::1

For systemd-networkd, use the identical instance because the bridge part above.

You also can use DHCP and SLAAC, however that requires working a DHCP and route
commercial server on the host. Options embrace dnsmasq. Doing so is left as
an train for the reader.

Note which you could hook up a number of containers to the identical bridge with NAT, so
you solely have to do that as soon as.

Connecting to the container

Now that the networking is configured, it is best to be capable to connect with the
container. For instance, with ssh and the bridge instance:

$ ping 192.0.2.124
PING 192.0.2.124 (192.0.2.124) 56(84) bytes of knowledge.
64 bytes from 192.0.2.124: icmp_seq=1 ttl=64 time=0.141 ms
^C
--- 192.0.2.124 ping statistics ---
1 packets transmitted, 1 acquired, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.141/0.141/0.141/0.000 ms
$ ssh [email protected]
...
root@debian:~# 

Binding information and directories from the host system

Another widespread factor to do is mounting sure information and directories from the
host machine into the container. This might be achieved within the [Files] part of
the .nspawn file. Here are some examples:

[Files]
# Mounts /srv/instance on the host with learn/write entry into the container
# on the similar path
# Equivalent to --bind=/srv/instance on the command line
Bind=/srv/instance

# Mounts /srv/instance on the host with read-only entry at /information
# contained in the container
# Equivalent to --bind-ro=/srv/instance:/information on the command line
BindLearnOnly=/srv/instance:/information

# Mounts /srv/instance on the host with learn/write entry into the container
# at /check, however with out recursively binding something mounted beneath
Bind=/srv/instance:/check:norbind

The third parameter permits comma-separated bind choices to be specified. There
are two associated to the model of bind mounting:

• rbind (the default): recursively bind mounts beneath the host path; and
• norbind: don’t bind mounts beneath the host path.

There are additionally 4 choices associated to UID mapping. Recall that containers are
given $y$ UIDs within the vary $[x, x+y)$ on the host. These options are:

• noidmap (the default): maps UID $z in [0, y)$ in the container to
  UID $x+z$ on the host, and out-of-range UIDs are shown as nobody inside
  the guest⁵;
• idmap: performs identity mapping, i.e. UID $z in [0, y)$ in the container
  will be mapped UID $z$ on the host, and out-of-range UIDs are shown as
  nobody;
• rootidmap: the root user inside the container is mapped to the owner of
  the path being bound, and every other user on the host will be shown as
  nobody; and
• owneridmap: the owner of the mountpoint inside the container is mapped to
  the owner of the path being bound, and every other user on the host will be
  shown as nobody.

You can use noidmap pretty easily to allow access to user $z$ inside the
container by granting access to $x+z$ on the host. You can do this with
traditional permissions, but I get lazy and just use POSIX ACLs instead, which
are so much more flexible. For example, to grant UID 13333337 write access to
everything under /srv/example, you can simply run (after installing the acl
package on Debian or the equivalent):

$ setfacl -Rm u:13333337:rwX /srv/example

If you want to also have this apply to new files created under the directory,
you can also run:

$ setfacl -Rdm u:13333337:rwX /srv/example

I may write an introduction to POSIX ACLs one day, but there are plenty of
resources online and figuring out the details is left as an exercise for the
reader for the time being.

Also note that you don’t have to bind mount directories. You can bind mount
files also. Needless to say, don’t grant the container more access than
necessary.

Sharing the GPU

Another interesting use is sharing the host’s GPUs with the guest. Note that
unlike doing VFIO passthrough on a KVM virtual machine, the device can be shared
between the host and multiple guests. This is accomplished by bind mounting
device files.

Nvidia GPUs

In the .nspawn file:

[Files]
Bind=/dev/nvidia0
Bind=/dev/nvidiactl
Bind=/dev/nvidia-modeset
Bind=/dev/nvidia-uvm
Bind=/dev/nvidia-uvm-tools

You’ll want to verify the motive force model contained in the visitor matches that on the
host. You’ll additionally want to permit the systemd unit entry by
systemctl edit systemd-nspawn@[name].service and placing within the following
strains:

[Service]
MachineAllow=/dev/nvidia0 rw
MachineAllow=/dev/nvidiactl rw
MachineAllow=/dev/nvidia-modeset rw
MachineAllow=/dev/nvidia-uvm rw
MachineAllow=/dev/nvidia-uvm-tools rw

Intel and AMD GPUs

In the .nspawn file:

Note that it will share entry of all GPUs. Passing by way of a selected GPU
is left as an train for the reader.

Limiting useful resource utilization

You can restrict CPU cores by setting CPU affinity like this:

[Exec]
CPUAffinity=0-1,8-9

You also can add CPU and reminiscence limits by way of commonplace systemd mechanisms by
enhancing the unit, resembling:

[Service]
# Note {that a} CPU quota > 100% means permitting a couple of core,
# so this implies two full cores are allowed:
CPUQuota=200%

MemoryMax=1G
MemorySwapMax=512M

# Limit I/O to 100 MB/s
IOReadBandwidthMax=100M
IOWriteBandwidthMax=100M

For extra particulars, see the systemd documentation on resource control.

Conclusion

And that’s a fast whirlwind tour of systemd-nspawn. We went over loads, however
that was largely as a result of there have been so many legitimate methods of setting issues up. With
systemd-nspawn, you’re free to configure issues in a means that pleases you
with full management. In the top, it’s similar to a digital machine. You can do
no matter you need!

Once you determine a setup that you simply like, you actually simply want a reputation and an IP
tackle allocation, earlier than working a couple of instructions to organize the picture throughout
the primary boot. Everything else simply requires enhancing the .nspawn file. You
may even make your personal script to automate every thing. Doing that, after all, is
left as an train for the reader.

Notes