From: Christian Brauner <christian@amutable.com>
Date: Wed, 6 May 2026 10:20:26 +0000 (+0200)
Subject: vmspawn,machinectl: integrate io.systemd.StorageProvider (#41910)
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4ddfd04a482a84dd86f8c9fe9b321f2404349589;p=thirdparty%2Fsystemd.git

vmspawn,machinectl: integrate io.systemd.StorageProvider (#41910)

PR #41776 introduced the io.systemd.StorageProvider Varlink interface
and
two backends ('block' exposes host block devices, 'fs' exposes regular
files / dirs / subvolumes under /var/lib/storage), plus the
storagectl(1)
CLI to enumerate them. The only consumer so far was mount.storage. This
series wires up the first of the three integrations called out in
TODO.md:

  systemd-vmspawn --bind-volume=PROVIDER:VOLUME[:CONFIG][:K=V,...]
      Boot-time attach. Drives added this way are immutable at runtime.

  io.systemd.MachineInstance.AddStorage  / .RemoveStorage
      Two new generic methods on the per-machine control socket. vmspawn
      implements them (this series); systemd-nspawn will reuse the same
      methods later.

  machinectl bind-volume   MACHINE PROVIDER:VOLUME[:CONFIG][:K=V,...]
  machinectl unbind-volume MACHINE PROVIDER:VOLUME
Runtime hotplug front-end: machinectl Acquire()s the fd locally and
      pushes it across to the target machine's MachineInstance socket.

Volumes are identified by a user-visible name "<provider>:<volume>"
(e.g.
"block:/dev/sda"). The 3rd 'config' field is opaque to the shared layer
and interpreted per backend — vmspawn maps it to a DiskType from
disk_type_table[] (virtio-blk default, virtio-scsi, nvme, scsi-cd; same
vocabulary as --extra-drive); future nspawn will read it as a mount
path.
---

4ddfd04a482a84dd86f8c9fe9b321f2404349589