<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 26, 2021, 14:06 Johannes Köhler <<a href="mailto:koehler.johannes@googlemail.com">koehler.johannes@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi systemd maintainer, again!<br>
<br>
with my last post i got a hint to<br>
follow the netiquette. My netiquette<br>
with now, was: read manpages and html<br>
searches before asking stupid questions... :)<br>
<br>
So to say, i am happy about private messages for adding<br>
concrete rules to that basic...<br>
<br>
During my tour through systemd there spawned<br>
some new questions:<br>
<br>
_systemd-nspawn_<br>
<br>
I think i realized: nspawn is using a machine and an<br>
image to create a virtual machine container, to run<br>
as process or thread within systemd.<br>
<br>
1. Can i use systemd-nspawn like QEMU?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">nspawn creates a container – *not* a virtual machine. It is much more like LXC or runC than qemu.</div><div dir="auto"><br></div><div dir="auto">Containers only virtualize certain things, such as filesystem or process tree, but they still share the host kernel, and the host will see each individual process running inside a container.</div><div dir="auto"><br></div><div dir="auto">(Usually containers even share the host filesystem, like fancy chroots, although I think nspawn also supports using loop-mounted disk images.)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. When iam installing an systemd linux distribution<br>
does this result in an systemd container with my<br>
linux installation (kernel, filesystem, etc.)?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Containers don't virtualize the kernel. But they *do* have their own init, so if the guest distro comes with systemd then your container will run systemd.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Further, - runs systemd-nspawn service<br>
before my linux kernel image is running?<br>
(because: my .host is a machine and an image, also)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No. As mentioned, nspawn containers are not virtual machines, they're just fancy chroots that are created using "namespace" features in the host kernel. So they cannot possibly run before the kernel.</div><div dir="auto"><br></div><div dir="auto">And the ".host" isn't really a container at all – it's only a convenience shortcut in systemd's tools (to allow things like 'machinectl shell'), but it doesn't mean that the host is virtualized in any way.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_/var/lib/machines_<br>
<br>
When trying to mount a btrfs subvolume as user home directory<br>
on boot, i got an html howto describing this by using<br>
the service var-lib-machines.mount. Later, i realized i<br>
can use mounts in /etc/fstab with btrfs subvolumes directly.<br>
<br>
1. What is the /var/lib/machines directory for?<br>
In the documentation of systemd it gets described with<br>
the "usecase" to keep machine images?</blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's the default location that's used for `machinectl start` and systemd-nspawn@.service.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What is doing<br>
the service var-lib-machines.mount? Like I told, i used it<br>
to mount a btrfs subvolume to my linux filesystem (home)<br>
during boot sequence. Since that, the service is starting<br>
on boot because it is still enabled but for mounting<br>
my home subvolume while fstab is doing the same...<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">.mount units are not services; they literally represent actual mounts.</div><div dir="auto"><br></div><div dir="auto">* If you manually mount something, systemd shows a virtual .mount unit for it.</div><div dir="auto"><br></div><div dir="auto">* If you create a real .mount unit and start it, systemd mounts the thing that's described in the .mount unit. That's all it does.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto"><br></div><div dir="auto">As for fstab... Fstab isn't actually doing anything on its own. During boot, all your fstab entries are *converted* to .mount units and *those* are used to actually mount things. So it is normal to see fstab entries duplicated to .mount units.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="https://cloudnull.io/2017/12/btrfs-subvolume-mounts-yes-you-can/" rel="noreferrer noreferrer" target="_blank">https://cloudnull.io/2017/12/btrfs-subvolume-mounts-yes-you-can/</a><br>
<br>
Is that a useless howto?<br>
<br>
THX and sincerely<br>
-kefko<br>
<br>
<br>
-- <br>
Wonderful vim doku:<br>
"When a mapping triggers itself, it will run forever"<br>
_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div></div></div>