[systemd-devel] /var/lib/machines
Mantas Mikulėnas
grawity at gmail.com
Sat Jun 26 13:45:12 UTC 2021
On Sat, Jun 26, 2021, 14:06 Johannes Köhler <koehler.johannes at googlemail.com>
wrote:
> Hi systemd maintainer, again!
>
> with my last post i got a hint to
> follow the netiquette. My netiquette
> with now, was: read manpages and html
> searches before asking stupid questions... :)
>
> So to say, i am happy about private messages for adding
> concrete rules to that basic...
>
> During my tour through systemd there spawned
> some new questions:
>
> _systemd-nspawn_
>
> I think i realized: nspawn is using a machine and an
> image to create a virtual machine container, to run
> as process or thread within systemd.
>
> 1. Can i use systemd-nspawn like QEMU?
>
nspawn creates a container – *not* a virtual machine. It is much more like
LXC or runC than qemu.
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.
(Usually containers even share the host filesystem, like fancy chroots,
although I think nspawn also supports using loop-mounted disk images.)
> 2. When iam installing an systemd linux distribution
> does this result in an systemd container with my
> linux installation (kernel, filesystem, etc.)?
>
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.
Further, - runs systemd-nspawn service
> before my linux kernel image is running?
> (because: my .host is a machine and an image, also)
>
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.
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.
> _/var/lib/machines_
>
> When trying to mount a btrfs subvolume as user home directory
> on boot, i got an html howto describing this by using
> the service var-lib-machines.mount. Later, i realized i
> can use mounts in /etc/fstab with btrfs subvolumes directly.
>
> 1. What is the /var/lib/machines directory for?
> In the documentation of systemd it gets described with
> the "usecase" to keep machine images?
It's the default location that's used for `machinectl start` and
systemd-nspawn at .service.
What is doing
> the service var-lib-machines.mount? Like I told, i used it
> to mount a btrfs subvolume to my linux filesystem (home)
> during boot sequence. Since that, the service is starting
> on boot because it is still enabled but for mounting
> my home subvolume while fstab is doing the same...
>
.mount units are not services; they literally represent actual mounts.
* If you manually mount something, systemd shows a virtual .mount unit for
it.
* 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.
>
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.
> https://cloudnull.io/2017/12/btrfs-subvolume-mounts-yes-you-can/
>
> Is that a useless howto?
>
> THX and sincerely
> -kefko
>
>
> --
> Wonderful vim doku:
> "When a mapping triggers itself, it will run forever"
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210626/5cafcf72/attachment.htm>
More information about the systemd-devel
mailing list