lvmpersist

Start PR on all PVs in a VG with a local key (exclusive access by default)

$ lvmpersist start --ourkey [0x1234abcd] --vg [vg_name]

$ lvmpersist start --ourkey [0x1234abcd] --access [sh] --vg [vg_name]

$ lvmpersist stop --ourkey [0x1234abcd] --vg [vg_name]

$ lvmpersist start --ourkey [0xmy_key] --removekey [0xother_key] --vg [vg_name]

$ lvmpersist remove --ourkey [0xmy_key] --removekey [0xother_key] --vg [vg_name]

$ lvmpersist read --vg [vg_name]

$ lvmpersist start --ourkey [0x1234abcd] --device [/dev/sdX] --device [/dev/mapper/mpathY]

lvmpersist is not a recognized command.
There is no standard syntax for a command with this name.

The term lvmpersist does not correspond to a standard or commonly recognized command within the Logical Volume Manager (LVM) suite on Linux. LVM, by its design, ensures that its configuration (Physical Volumes, Volume Groups, and Logical Volumes) is inherently persistent across system reboots. This persistence is managed by LVM's daemon (like lvmlockd in some configurations) and the LVM metadata stored on disk. When a system boots, LVM utilities scan for and activate Volume Groups and Logical Volumes based on this metadata, making them available for use. Therefore, there isn't a specific command named lvmpersist required to 'make LVM persist' as it is a fundamental characteristic of LVM.

While lvmpersist itself doesn't exist, LVM commands like vgchange, lvchange, vgimport, and lvconvert play roles in how LVM entities are activated, configured, and thus how their state is managed and persisted on the system. It's possible the term is a misconception, a typo for another LVM command (e.g., vgpersist which exists in clustered LVM but has a different scope), or a reference to a custom script.

Non-existence: The primary caveat is that lvmpersist is not a standard Linux LVM command. Attempting to execute it will result in a "command not found" error.

Conceptual Misunderstanding: The term might arise from a misunderstanding of how LVM inherently manages persistence. LVM's configuration is stored on disk and automatically processed at boot time.

Possible Typo/Alternative: It could be a typo for another LVM command, or perhaps refers to the functionality provided by LVM activation mechanisms or cluster-related commands like vgpersist (used in certain clustered LVM environments to mark a VG for persistent activation, but not universally present or used in standalone LVM).

LVM configurations persist because LVM metadata is written directly to the Physical Volumes (PVs). During system boot, LVM initialization scripts (e.g., lvm.conf, systemd units like lvm2-pvscan.service, lvm2-vgscan.service, lvm2-lvmetad.service, lvm2-activation.service) scan for these metadata structures, read the configuration of Volume Groups and Logical Volumes, and then activate them, making them accessible to the operating system. This automatic process eliminates the need for a manual lvmpersist command.

As lvmpersist is not a standard LVM command, there is no development or usage history specifically for it within the LVM project. The concept of LVM configuration persistence, however, has been fundamental to LVM since its inception, ensuring that defined storage structures are available after system reboots. This is an inherent design feature rather than a command-driven action.

lvm(8), vgchange(8), lvchange(8), pvscan(8), vgscan(8), lvscan(8), lvmlockd(8), vgpersist(8)