]> git.ipfire.org Git - thirdparty/systemd.git/commit - meson_options.txt
storagetm: add new systemd-storagetm component
authorLennart Poettering <lennart@poettering.net>
Fri, 27 Oct 2023 12:25:49 +0000 (14:25 +0200)
committerLennart Poettering <lennart@poettering.net>
Thu, 2 Nov 2023 13:19:32 +0000 (14:19 +0100)
commit1761066b135f1a322c446f102343ea4aa61fe3ee
tree7e4a8052f9a7e39a1f902f55520f7b0ef29c923b
parent3b516db71d7e394b74653dfd81c27a7b6a65d453
storagetm: add new systemd-storagetm component

This implements a "storage target mode", similar to what MacOS provides
since a long time as "Target Disk Mode":

        https://en.wikipedia.org/wiki/Target_Disk_Mode

This implementation is relatively simple:

1. a new generic target "storage-target-mode.target" is added, which
   when booted into defines the target mode.

2. a small tool and service "systemd-storagetm.service" is added which
   exposes a specific device or all devices as NVMe-TCP devices over the
   network.  NVMe-TCP appears to be hot shit right now how to expose
   block devices over the network. And it's really simple to set up via
   configs, hence our code is relatively short and neat.

The idea is that systemd-storagetm.target can be extended sooner or
later, for example to expose block devices also as USB mass storage
devices and similar, in case the system has "dual mode" USB controller
that can also work as device, not just as host. (And people could also
plug in sharing as NBD, iSCSI, whatever they want.)

How to use this? Boot into your system with a kernel cmdline of
"rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on
screen the precise "nvme connect" command line to make the relevant
block devices available locally on some other machine. This all requires
that the target mode stuff is included in the initrd of course. And the
system will the stay in the initrd forever.

Why bother? Primarily three use-cases:

1. Debug a broken system: with very few dependencies during boot get
   access to the raw block device of a broken machine.

2. Migrate from system to another system, by dd'ing the old to the new
   directly.

3. Installing an OS remotely on some device (for example via Thunderbolt
   networking)

(And there might be more, for example the ability to boot from a
laptop's disk on another system)

Limitations:

1. There's no authentication/encryption. Hence: use this on local links
   only.

2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd
   have a read-only mode, for security reasons, and default to it.

Future love:

1. We should have another mode, where we simply expose the homed LUKS
   home dirs like that.

2. Some lightweight hookup with plymouth, to display a (shortened)
   version of the info we write to the console.

To test all this, just run:

    mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
meson.build
meson_options.txt
src/storagetm/meson.build [new file with mode: 0644]
src/storagetm/storagetm.c [new file with mode: 0644]
units/meson.build
units/storage-target-mode.target [new file with mode: 0644]
units/systemd-storagetm.service.in [new file with mode: 0644]