I don't see why systemd is at the core of all those graphs. Why do we need that particular program to run containers? Or does systemd mean, in this context, "any daemon-controlling process"?
[0] https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-f...
Personal opinion: If you're already using systemd on the host, nspawn containers are trivially easy to create, boot, and maintain. Running systemd as the guest init allows you to use `systemctl -M <machine>` and `journalctl -M <machine>` the same way you would for the host, and the guest process tree is exposed in the host's `systemctl status`.
But yea, first look, it seems usefull :-)
- I can use the same tools to administer both host and guests (systemctl and journalctl).
- cgroups and namespaces are managed the same way on both host and guests.
- I can integrate containers (via .nspawn and .service units) with my host init/supervision daemon, like any other systemd service, without translating from one configuration format to another.
- Because of the above, resource/quota constraints for a single container or groups of containers can be described via a common configuration.