systemd-machined.service
/usr/lib/systemd/systemd-machined
systemd-machined is a system service that keeps track of locally running virtual machines and containers.
systemd-machined is useful for registering and keeping track of both OS containers (containers that share the host kernel but run a full init system of their own and behave in most regards like a full virtual operating system rather than just one virtualized app) and full virtual machines (virtualized hardware running normal operating systems and possibly different kernels).
systemd-machined should not be used for registering/keeping track of application sandbox containers. A machine in the context of systemd-machined is supposed to be an abstract term covering both OS containers and full virtual machines, but not application sandboxes.
Machines registered with machined are exposed in various ways in the system. For example:
See systemd-nspawn(1) for some examples on how to run containers with OS tools.
If you are interested in writing a VM or container manager that makes use of machined, please have look at m[blue]Writing Virtual Machine or Container Managersm[][2]. Also see the m[blue]New Control Group Interfacesm[][3].
The daemon provides both a C library interface (which is shared with systemd-logind.service(8)) as well as a D-Bus interface. The library interface may be used to introspect and watch the state of virtual machines/containers. The bus interface provides the same but in addition may also be used to register or terminate machines. For more information please consult sd-login(3) and org.freedesktop.machine1(5) and org.freedesktop.LogControl1(5).
A small companion daemon systemd-importd.service(8) is also available, which implements importing, exporting, and downloading of container and VM images.
For each container registered with systemd-machined.service that employs user namespacing, users/groups are synthesized for the used UIDs/GIDs. These are made available to the system using the m[blue]User/Group Record Lookup API via Varlinkm[][4], and thus may be resolved with userdbctl(1) or the usual glibc NSS calls.
systemd(1), machinectl(1), systemd-nspawn(1), nss-mymachines(8), systemd.special(7)