systemd-lvm-auto-generator analogous to systemd-gpt-auto-generator

[risen]

I was wondering if there's any way to store GPT-style partition type GUIDs in LV metadata?

It would be useful to automatically discover, enable, and mount LVs, using a systemd-lvm-auto-generator, similar to how systemd-gpt-auto-generator does it.

See also: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

I clearly wasn't the first to think of something like this, see for instance: systemd/systemd#1727

This would also be useful to have a systemd-homed homedir on lvm, which is currently not possible. See: systemd/systemd#15273

Thank you.

[prajnoha]

It is possible to add tags to whole VGs as well as individual LVs (which may be just anything as needed, like UUIDs). There's also support for activating the LVs based on the tags where we can reference by using the "@" prefix (see also activation/auto_activation_volume_list in /etc/lvm/lvm.conf). So I think the infrastructure on LVM side is already there and we would just need to generate the appropriate .mount systemd units for these volumes.

[prajnoha]

The only thing is that there may be different mechanisms for activation during initramfs stage (either direct or event-based) in various distributions and we would need to have a closer look at these to integrate this properly so it doesn't interfere. But I think the idea is feasible.

[risen]

I see, should a tag be prefixed with something like for example @type:773f91ef-66d4-49b5-bd83-d683bf40ad16 or @dps:773f91ef-66d4-49b5-bd83-d683bf40ad16, or …?

Also, I looked at gpt-auto-generator.c and it seems to have a lot of logic for setting up unit files for mount, automount, verity, cryptsetup, growfs etc. More complicated than I imagined, and this makes me wonder: should a hypothetical systemd-lvm-auto-generator live in the systemd tree, or in the lvm2 tree like @poettering suggested in 2015 in systemd/systemd#1727 (comment) ?

[prajnoha]

Honestly. I can't judge at the moment, because I haven't been tracking what all the gpt-auto-generator is handling - it was out of my interest a bit, so I need to have a look at it first. If it contains support for cryptsetup, one might say that it's just a DM subsystem like any other (like LVM), but it's true this one is simpler (doesn't need to care about more than one device at a time). I'll see what we could do here...

[prajnoha]

OK, so I've had a look at various uses of the DPS throughout systemd. I'm a bit afraid that the DPS represented by GPT partitions is just too much fused with the systemd code right now. At the same time, it seems, systemd does not expect anything else than the GPT partitions at the moment. I see this as an issue.

We could probably support some of the use cases, like automatic discovery of root/home/... and avoiding the extra kernel command line options, fstab configuration and/or explicit systemd mount unit configuration. But besides using the DPS on bare metal, systemd also uses DPS for image creation, its dissection where various parts are identified, then executed either as a container (this is hard to support considering LVM/DM is activated globally - there's no support for namespaces for block devices) or a VM (I can image supporting this in a way, but it would not be that straightforward as with partitions).

Thing is, systemd circumvents (implicitly) the lack of namespaces for block devices by having the loop device in the middle where the image is attached through a loop device. In that case, each partition automatically gains a unique name, e.g. you have a loop0, then the partitions on such a loop device are represented as loop0p1, loop0p2.... If loop0 is used already, then another loop device is used like loop1, then the partitions are loop1p1, loop1p2.... So you implicitly get a unique name here. While with the LVs, the name property is global: if you have an LV named myvg/mylv, it will stay that way untill renamed directly, even if they're on top of a loop device - that won't help here. And, of course, you can't activate the LVs with the same name at the same time, even though they would be a part of different "images".

So at this moment, we would need to specify exactly all the use cases we would like to see support for DPS (or rather "DLVS" - "Discoverable Logical Volume Specification" here). Based on that, we could weigh more whether it makes sense to look into this more or not.

Looking at the systemd code, I can see there's just too much logic already implemented there, as you already pointed out. That would mean either copying much of the functionality to the hypothetical new "lvm-auto-generator" or we would need to extend the existing systemd codebase itself (which is probably a no-go as people from systemd simply don't like LVM, that's just a fact - so I can't imagine having pieces of LVM functionality within systemd). Even with that, as I already mentinoed, the systemd-gpt-auto-generator is just a tip of the iceberg where the DPS is used in systemd. Also, using GPT partitions on top of the LVs doesn't make much sense (like I've noticed in systemd/systemd#15273 where people try to workaround the limitations). So if we were going to support any of this, we would need to support that directly so that we could really go without the GPT partitions here and at the same time systemd still integrating with that.

That said, supporting certain scenarios is still possible, we just need to select them from all the existing ones where DPS using GPT partitions is used in systemd now.