Post B7ijmi5EKNcYZJY8uG by pid_eins@mastodon.social
 (DIR) More posts by pid_eins@mastodon.social
 (DIR) Post #B7ijmdTrRNLuIG2F6W by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       2️⃣6️⃣ Here's the 26th post highlighting key new features of the recently released v261 release of systemd. #systemd261 #systemd When dealing with VMs, you have to think about dealing with storage, too: how do you connect your block devices and file systems to your VMs.For a while now systemd has been shipping systemd-vmspawn, a small wrapper around qemu, which integrates it in various ways into the system, for example registers it with systemd-machined and a variety of other things.
       
 (DIR) Post #B7ijmdwZicJxjJTArQ by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       With v261 systemd-vmspawn gained support for a "storage provider" API that allows you to connect arbitrary storage resources to systemd-vmspawn. More specifically, there's now --bind-volume= – which is inspired by --bind= (which allows you to bind mount any local directory into the VM). --bind-volume= wraps access to a Varlink API, consisting of pretty much one call: io.systemd.StorageProvider.Acquire().
       
 (DIR) Post #B7ijmfGSo9p9pHmZV2 by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       You use --bind-volume= by specifying a provider name and a volume name which results in said Varlink call to be made to the Varlink service indicated by the provider name. The call itself is very simple: it takes the volume name, and is supposed to return a file descriptor to the storage in question, either a directory, a regular file or a block device fd.Now the fun part about this is that *any* service can implement this Varlink interface, and thus be trivially connected to a new…
       
 (DIR) Post #B7ijmgeFfCRk7Lv5DU by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       …systemd-vmspawn instance, in demand, when the VM is invoked.By default systemd includes two providers of that implement that interface: systemd-storage-block and systemd-storage-fs. The former exposes all local block devices via the API, the latter regular files and dirs in /var/lib/storage/ – but of course the intention here is that the interface becomes generally popular and various storage services could implement it too.In upcoming systemd versions we intend to introduce the concept…
       
 (DIR) Post #B7ijmi5EKNcYZJY8uG by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       …also to regular service management (i.e. think BindVolume= in a service unit file that just connects to a volume service of choice) and systemd-nspawn. The idea is not new of course, Kubernetes has something similar, and this does take inspiration from that. The concept in systemd is decidedly more low-level and generic however, and if I may say so technically prettier (i.e. we only deal in fds.).
       
 (DIR) Post #B7ijmioxaMCUr8wfBY by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       Anyway: if you maintain a storage stack of some kind, consider implementing the simple Varlink API, please!