Lennart Poettering
9️⃣ Here's the 9th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
I am sure you are aware of systemd-nspawn, systemd's minimal container manager focussed on full OS containers, that can boot up a Linux image from an OS in a disk image or from a directory. systemd-nspawn was originally a development tool, to make it easy for us to develop the service manager without constantly having to reboot.
Nowadays it's a lot more than that, …
Lennart Poettering
@mxk we kinda have that now with mountfsd/nsresourced, see earlier installment of this series. Not entirely polished yet.
Lennart Poettering
… authenticated OS images via dm-verity/DDI and there's so much more.
Now, I personally use nspawn daily, for developing systemd, testing integration and many other aspects and a lot more. But sometimes it's not enough for my work. For example, because nspawn directly transitions into the service manager it doesn't go through an initrd, so it cannot be used for test an initrd, even though that's a crucial part of developing an OS.
mxk
@pid_eins you could eliminate half of my use cases to use VMs over Containers, if systemd-nspawn would offer a container aware interface for creating loopback-mounts.
Lennart Poettering
… maybe not quite as popular as docker, but it conquered many other areas, for example build systems and more.
There's one facet nspwan is particularly good at: we use it to showcase new integration features between the host systemd and containers. nspawn for example natively supports propagating credentials down to its payload, or supports sd_notify() ready notfications for the service manager in the payload. It allows binding a host user into the container via --bind-user=, or…
Lennart Poettering
The idea is that we provide a roughly command line equivalent interface to VMs as for containers, so that it really is as easy to invoke a VM as it already is to invoke a container, supporting both boot from DDIs and boot from directories.
And one thing in particular we have a focus on here: that the integration points that make it so nice to use nspawn are also available in vmspawn, wherever we can possibly do that. i.e. credentials, sd_notify, and all that other stuff.
Lennart Poettering
With v256 vmspawn is relatively complete now. For example it now registers with machinectl, also supports credentials, sd_notify, and so much more.
At this point, for my daily work it's now as trivial to boot a relatively fully featured VM (with TPM, SecureBoot, and all that fancy new-fangled stuff) as it is to to run a full OS container, and all I have to do is replace "n" by "vm" in the command line I use.
We also started to switch over much of systemd's test suite to use vmspawn.
Lennart Poettering
And life has gotten so much better with it.
(Much of the work to get vmspawn up to speed for use in the integration test suite was implemented by Codethink btw, supported by the STF).
And that's all for now. Let's see if I'll manage to do a 10th installment soon.
Lennart Poettering
It also doesn't bother with a boot loader, since containers after all share the same kernel, there's no boot loader involved anymore. But in systemd we have sd-boot after all, which is a modern boot loader with many security features we need to work with. Per-container TPMs are also not really a thing.
Hence, in a recent systemd version we added systemd-vmspawn. It's a small wrapper around qemu, which has the point of making it as nice and simple to use qemu as it is to use nspawn.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.