Systemd-nspawn - Revision history

Y266shen: bookworm

2025-04-25T15:18:34Z

bookworm

← Older revision		Revision as of 10:18, 25 April 2025
Line 19:		Line 19:
	Now bootstrap the rootfs:		Now bootstrap the rootfs:
	<pre>		<pre>
	debootstrap --variant=minbase --include=~~systemd,systemd-sysv~~,systemd-container,~~iproute2,inetutils-ping,ifupdown,procps,less,nano~~ ~~bullseye~~ ~~/var/lib/machines/machine1~~ http://mirror.csclub.uwaterloo.ca/debian		debootstrap --variant=minbase --include=dbus,systemd-container,vim bookworm . http://mirror.csclub.uwaterloo.ca/debian
	</pre>		</pre>
	Note that the <code>systemd-container</code> package <b>must</b> be installed in the guest.		Note that the <code>systemd-container</code> package <b>must</b> be installed in the guest.
Line 38:		Line 38:
	# set FQDN		# set FQDN
	nano /etc/hosts		nano /etc/hosts
	# ~~set~~ up network ~~config~~		# Use systemd-networkd for network management. See
	~~nano~~ /etc/network/~~interfaces~~		vim /etc/systemd/network/10-hostbr0.network
	exit		exit
	</pre>		</pre>
Line 111:		Line 111:
	* veth2, which is attached to br2 on the host		* veth2, which is attached to br2 on the host

	Make sure you update /etc/network/~~interfaces~~ in the container accordingly.		Make sure you update /etc/systemd/network/10-hostbr.network in the container accordingly.

Merenber: /* Quickstart */

2022-04-28T21:48:42Z

Quickstart

← Older revision		Revision as of 16:48, 28 April 2022
Line 73:		Line 73:
	<pre>		<pre>
	machinectl shell machine1		machinectl shell machine1
			</pre>

			<b>Note</b>: if you see the error <code>sh: 2: exec: : Permission denied</code>, append /bin/bash to the end of the command:
			<pre>
			machinectl shell machine1 /bin/bash
	</pre>		</pre>

Merenber: /* Multiple network interfaces */

2021-12-29T21:44:05Z

Multiple network interfaces

← Older revision		Revision as of 16:44, 29 December 2021
Line 81:		Line 81:

	== Multiple network interfaces ==		== Multiple network interfaces ==
	Unfortunately systemd does not have a built-in way to create [https://github.com/systemd/systemd/issues/11087 multiple bridged network interfaces]. Thankfully, it's not too difficult to accomplish this using the <code>VirtualEthernetExtra</code> option and a systemd~~-drop~~ in; the idea is to create some extra veth pairs and then manually attach them to the bridge.		Unfortunately systemd does not have a built-in way to create [https://github.com/systemd/systemd/issues/11087 multiple bridged network interfaces]. Thankfully, it's not too difficult to accomplish this using the <code>VirtualEthernetExtra</code> option and a systemd drop-in; the idea is to create some extra veth pairs and then manually attach them to the bridge.

	Let's say you have three bridges on the host: br0, br1 and br2, and you want the container to be attached to all three. Make your nspawn file look like this:		Let's say you have three bridges on the host: br0, br1 and br2, and you want the container to be attached to all three. Make your nspawn file look like this:

Merenber: /* Multiple network interfaces */

2021-12-29T21:25:13Z

Multiple network interfaces

← Older revision		Revision as of 16:25, 29 December 2021
Line 92:		Line 92:
	VirtualEthernetExtra=ve-machine1-2:veth2		VirtualEthernetExtra=ve-machine1-2:veth2
	</pre>		</pre>
	Now run <code>systemctl edit systemd-nspawn@machine1 and paste the following:		Now run <code>systemctl edit systemd-nspawn@machine1</code> and paste the following:
	<pre>		<pre>
	[Service]		[Service]

Merenber at 21:24, 29 December 2021

2021-12-29T21:24:35Z

← Older revision		Revision as of 16:24, 29 December 2021
Line 79:		Line 79:
	systemctl enable systemd-nspawn@machine1		systemctl enable systemd-nspawn@machine1
	</pre>		</pre>

			== Multiple network interfaces ==
			Unfortunately systemd does not have a built-in way to create [https://github.com/systemd/systemd/issues/11087 multiple bridged network interfaces]. Thankfully, it's not too difficult to accomplish this using the <code>VirtualEthernetExtra</code> option and a systemd-drop in; the idea is to create some extra veth pairs and then manually attach them to the bridge.

			Let's say you have three bridges on the host: br0, br1 and br2, and you want the container to be attached to all three. Make your nspawn file look like this:
			<pre>
			...
			[Network]
			Bridge=br0
			# These will be manually bridged to the host
			VirtualEthernetExtra=ve-machine1-1:veth1
			VirtualEthernetExtra=ve-machine1-2:veth2
			</pre>
			Now run <code>systemctl edit systemd-nspawn@machine1 and paste the following:
			<pre>
			[Service]
			ExecStartPost=/usr/sbin/ip link set dev ve-machine1-1 master br1
			ExecStartPost=/usr/sbin/ip link set dev ve-machine1-1 up
			ExecStartPost=/usr/sbin/ip link set dev ve-machine1-2 master br2
			ExecStartPost=/usr/sbin/ip link set dev ve-machine1-2 up
			</pre>
			In the container, there will be three interfaces:

			* host0, which is attached to br0 on the host
			* veth1, which is attached to br1 on the host
			* veth2, which is attached to br2 on the host

			Make sure you update /etc/network/interfaces in the container accordingly.

Merenber at 21:04, 29 December 2021

2021-12-29T21:04:29Z

← Older revision		Revision as of 16:04, 29 December 2021
Line 1:		Line 1:
	[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn] is a simpler alternative to [[LXC]] which works well on modern versions of Debian (and, unlike LXC, it does not break very critical systemd services running in containers). For "pet" containers, we should be using systemd-nspawn; for "cattle" containers, [[Podman]] is more appropriate.		[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn] is a simpler alternative to [https://wiki.csclub.uwaterloo.ca/Virtualization_(LXC_Containers) LXC] which works well on modern versions of Debian (and, unlike LXC, it does not break very critical systemd services running in containers). For "pet" containers, we should be using systemd-nspawn; for "cattle" containers, [[Podman]] is more appropriate.

	Some light reading:		Some light reading:

Merenber: Created page with "[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn] is a simpler alternative to LXC which works well on modern versions of Debian (and, u..."

2021-12-29T21:03:00Z

Created page with "[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn] is a simpler alternative to LXC which works well on modern versions of Debian (and, u..."

New page

[https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn] is a simpler alternative to [[LXC]] which works well on modern versions of Debian (and, unlike LXC, it does not break very critical systemd services running in containers). For "pet" containers, we should be using systemd-nspawn; for "cattle" containers, [[Podman]] is more appropriate.

Some light reading:

* https://wiki.debian.org/nspawn
* https://wiki.archlinux.org/title/Systemd-nspawn

== Quickstart ==
In the example below, we will create a container called 'machine1'.

Create a directory for the rootfs:
<pre>
mkdir /var/lib/machines/machine1
</pre>
Or, if you are using an LVM volume, just create a symlink in /var/lib/machines to where the LV is mounted:
<pre>
ln -s /vm/machine1 /var/lib/machines/machine1
</pre>
Now bootstrap the rootfs:
<pre>
debootstrap --variant=minbase --include=systemd,systemd-sysv,systemd-container,iproute2,inetutils-ping,ifupdown,procps,less,nano bullseye /var/lib/machines/machine1 http://mirror.csclub.uwaterloo.ca/debian
</pre>
Note that the <code>systemd-container</code> package <b>must</b> be installed in the guest.

Now do a bit of setup in the rootfs:
<pre>
chroot /var/lib/machines/machine1
# Only do this if you want to use `machinectl login`
passwd -d root
cat <<EOF >>/etc/securetty
pts/0
pts/1
pts/2
pts/3
EOF
# set hostname
echo machine1 > /etc/hostname
# set FQDN
nano /etc/hosts
# set up network config
nano /etc/network/interfaces
exit
</pre>
Now paste the following into /etc/systemd/nspawn/machine1.nspawn:
<pre>
[Exec]
Boot=yes
Hostname=machine1
PrivateUsers=no

[Network]
Bridge=br0
</pre>
Replace 'br0' by the bridge interface on the host to which the container should be attached (a veth pair will be created when the container starts up).

Also make sure to set 'PrivateUsers=no', because by default systemd-nspawn uses some randomized UID/GID mapping which makes it difficult to migrate the container to a different system.

Now start the container:
<pre>
systemctl start systemd-nspawn@machine1
</pre>
Or alternatively, using <code>machinectl</code>:
<pre>
machinectl start machine1
</pre>

To login to a container via an emulated serial console (I don't recommend doing this, since the TTY gets screwed up):
<pre>
machinectl login machine1
</pre>

Attach to a running container (similar to <code>lxc-attach</code>):
<pre>
machinectl shell machine1
</pre>

<b>Important</b>: make sure the container starts up at boot:
<pre>
systemctl enable systemd-nspawn@machine1
</pre>