LVMAUTOACTIVATION(7)

📦

version 2.03.44 · 11 versions

💖 LVMAUTOACTIVATION(7) — LVM autoactivation 💖

okay bestie, so this is lvmautoactivation from the Miscellaneous Information Manual, section 7, and it's literally the whole lore on how LVM wakes your volumes up all by itself. grab a snack, this one's a ride 🎀

✨ NAME ✨

lvmautoactivation — LVM autoactivation

it's giving the automatic activation arc and honestly? iconic.

🌸 DESCRIPTION 🌸

So. Autoactivation is when LVs get activated automatically by the system, as a reaction to LVM devices being attached to your machine. The vibe check: once all the PVs in a VG have been attached, the VG is considered complete, and then the LVs inside that VG get activated. no manual lift, no cap 💅

You can block autoactivation though — for whole VGs, or for specific LVs — using vgchange or lvchange --setautoactivation n. And there's another way to limit it: the lvm.conf(5) setting auto_activation_volume_list. two tools, same energy 🫶

🦋 event autoactivation

LVM autoactivation is "event based" — meaning complete VGs get activated in response to uevents, which happen either during system startup or literally any time after the system has started. The old form of autoactivation was "static", where complete VGs were activated at a fixed point during system startup by a systemd service, and not in response to events. old news, we don't stan anymore ✨

Event based autoactivation is driven by udev, udev rules, and systemd. Here's the chain, bestie: when a device is attached to a machine, the kernel generates a uevent to notify userspace about the new device. systemd-udev runs udev rules to process that new device. Those udev rules use blkid to identify the device as an LVM PV, and then they execute the lvm-specific udev rule for the device — which is the thing that actually triggers autoactivation. 🔥

There are two variations of event based autoactivation that may be used on a system, depending on which LVM udev rule is installed (you'll find them in /lib/udev/rules.d/). Here's the step-by-step of each rule that leads to autoactivation:

🎀 `69-dm-lvm-metad.rules`

device /dev/name with major:minor X:Y is attached to the machine
systemd/udev runs blkid to identify /dev/name as an LVM PV
udev rule 69-dm-lvm-metad.rules is run for /dev/name
the lvm udev rule runs the systemd service lvm2-pvscan@X:Y.service
the lvm2-pvscan service runs:

pvscan --cache -aay --major X --minor Y

pvscan reads the device, records that the PV is online (see pvs_online), and checks if the VG is complete.
if the VG is complete, pvscan creates the vgs_online temp file, and activates the VG.
the activation command output can be seen from systemctl status lvm2-pvscan*

🎀 `69-dm-lvm.rules`

device /dev/name with major:minor X:Y is attached to the machine
systemd/udev runs blkid to identify /dev/name as an LVM PV
udev rule 69-dm-lvm.rules is run for /dev/name
the lvm udev rule runs:

pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/name

pvscan reads the device, records that the PV is online (see pvs_online), and checks if the VG is complete.
if the VG is complete, pvscan creates the vgs_online temp file, and prints the name of the VG for the udev rule to import:

LVM_VG_NAME_COMPLETE='vgname'

if the lvm udev rule sees LVM_VG_NAME_COMPLETE from pvscan, it activates the VG using a transient systemd service named lvm-activate-<vgname>.
the lvm-activate-<vgname> service runs:

vgchange -aay --autoactivation event <vgname>

the activation command output can be seen from journalctl -u lvm-activate-<vgname>

💅 pvscan options 💅

these are the flags doing the heavy lifting, bestie. know them, love them:

--cache — read the <device> arg (and only that device), and record that the PV is online by creating the /run/lvm/pvs_online/<pvid> file containing the name of the VG and the device for the PV. 🫶
-aay — activate the VG from the pvscan command. this one includes an implicit --checkcomplete and --vgonline, sneaky little combo ✨
--checkcomplete — check if the VG is complete, i.e. all PVs are present on the system, by checking /run/lvm/pvs_online/<pvid> files.
--vgonline — create /run/lvm/vgs_online/<vgname> if the VG is complete. this is used to make sure only one command performs activation. no double-activating, we don't do that here 💀
--autoactivation event — inform the command it is used for event based autoactivation.
--listvg — print the name of the VG using the device.
--udevoutput — only print output that can be imported to the udev rule, using the udev environment key format, i.e. NAME='value'.
--journal=output — send standard command output to the journal (this is what you want when stdout is reserved for udev output).

🌈 PVs on LVs 🌈

okay this part is lowkey galaxy brain. an active LV can be used as a PV for another VG. this is sometimes called a layered or nested VG. like, an LV in an outer VG can contain a PV and an inner VG. but — and this is the important bit — the outer LV must be active before commands can find or use the inner PV. periodt. 👑

By default, LVM does not scan LVs for PVs. why? because this avoids finding LVM metadata inside guest or VM disk images that are stored on an LV. 🙈

Do not enable scanning for all LVs unless every such LV is intended to be used as an LVM PV by the host. fr fr, don't do it.

To allow commands to find intentionally layered PVs, set devices/scan_lvs to 1 in lvm.conf(5). When this setting is enabled, restrict the LVs that LVM scans to the intended storage LVs. Use the LVM devices file described in lvmdevices(8), or, when the devices file is disabled, use the lvm.conf filter. The devices file must include the outer LV device as well as any other devices needed by the command. 🎀

For example, after configuring scan_lvs and the applicable devices-file or filter restriction, an outer LV can be prepared and used as follows:

# lvchange -ay outer_vg/storage_lv
# pvcreate /dev/outer_vg/storage_lv
# vgcreate inner_vg /dev/outer_vg/storage_lv
# vgchange -ay inner_vg
# pvs /dev/outer_vg/storage_lv
# vgs inner_vg

The setting enables explicit LVM commands to scan active LVs, but it does not enable event-based autoactivation of an inner VG. The installed 69-dm-lvm.rules deliberately ignores a PV found on an LV — again, to avoid host activation of guest VGs. To opt in to event-based autoactivation, add a custom udev rule that sets LVM_PVSCAN_ON_LVS=1 only for the selected storage LVs. The rule must sort before 69-dm-lvm.rules and must match the local naming or identification convention for those LVs. 💅

For example, a file named /etc/udev/rules.d/68-lvm-pv-on-lv.rules can use LVM's udev properties to select an outer VG and LV:

ACTION=="add|change", ENV{DM_UUID}=="LVM-?*", \
ENV{DM_VG_NAME}=="outer_vg", ENV{DM_LV_NAME}=="storage_lv", \
ENV{LVM_PVSCAN_ON_LVS}="1"

Replace the VG and LV matches with a sufficiently narrow local rule. In particular:

do not use a rule that sets this variable for every LV — it can cause the host to scan and activate VGs belonging to guest images. 😭 that's the nightmare scenario bestie.

The properties used in the example are populated by the device-mapper udev rules that run before this rule.

After adding or changing the custom rule, reload udev rules and cause an event for the active outer LV, for example:

# udevadm control --reload
# udevadm trigger --action=change /dev/outer_vg/storage_lv
# udevadm settle

When udev recognizes the contained PV, its usual pvscan flow records the inner PV as online. If all PVs in the inner VG are present and eligible for autoactivation, the inner VG is activated. Check the result with vgs or lvs, and inspect the transient lvm-activate-inner_vg unit journal if activation does not occur. 🔍

At boot, the outer VG and storage LV must first be eligible for and complete enough to be autoactivated. Activation of that LV then produces the event that lets the udev rule discover and activate the inner VG. it's a whole relay race and I'm obsessed 🦋

🍓 run files 🍓

Autoactivation commands use a number of temporary files in /run/lvm (with the expectation that it is cleared between boots). yes, /run gets wiped, that's the point, slay ✨

pvs_online — pvscan --cache creates a file here for each PV that is attached. The file is named with the PVID and contains the VG name and device information. The existence of the file is used to determine when all PVs for a given VG are present. The device information in these files is also used to optimize locating devices for a VG when the VG is activated.
pvs_lookup — pvscan --cache creates a file here named for a VG (if one doesn't already exist.) The file contains a list of PVIDs in the VG. This is needed when a PV is processed which has no VG metadata, in which case the list of PVIDs from the lookup file is used to check if the VG is complete.
vgs_online — the first activation command (pvscan or vgchange) to create a file here, named for the VG, will activate the VG. This resolves a race when concurrent commands attempt to activate a VG at once. no fighting, first one wins 🏆

🌸 static autoactivation 🌸

A static autoactivation method is no longer provided by lvm. Setting event_activation=0 still disables event based autoactivation.

WARNING: disabling event activation without an alternative may prevent a system from booting. 🚨 like, genuinely. be careful.

A custom systemd service could be written to run autoactivation during system startup, in which case disabling event autoactivation may be useful. just know what you're doing bestie 💀

💜 lvm.conf filter 💜

Device symlinks from /dev/disk/ can be used in the lvm.conf(5) filter to guard against changes in kernel device names. The /dev/disk/by-path/ or /dev/disk/by-id/ prefixes should be included in the filter names — these prefixes help lvm detect that symlink names are used. Filters containing symlinks require special matching by commands run in the lvm udev rule. ✨

Common symlinks, such as those beginning with wwn-, scsi-, pci-, or lvm-pv-uuid-, are recommended. Uncommon or custom symlinks created by custom udev rules may be less reliable. If a custom udev rule creates symlinks used in the lvm filter, then the udev rule should be started prior to the lvm rule. 🎀

✨ EXAMPLES ✨

okay so picture this: your volume group vg is literally holding two physical volumes. iconic. here's the proof:

# pvs -o name,vgname,uuid /dev/sdb /dev/sdc
  PV         VG PV UUID
  /dev/sdb   vg 1uKpaT-lFOZ-NLHX-j4jI-OBi1-QpdE-HZ5hZY
  /dev/sdc   vg 5J3tM8-aIPe-2vbd-DBe7-bvRq-TGj0-DaKV2G

💾 Use of `--cache`

When you run pvscan --cache on each PV, it marks them as online. watch:

# pvscan --cache /dev/sdb
  pvscan[12922] PV /dev/sdb online.
# pvscan --cache /dev/sdc
  pvscan[12923] PV /dev/sdc online.

# cat /run/lvm/pvs_online/1uKpaTlFOZNLHXj4jIOBi1QpdEHZ5hZY
8:16
vg:vg
dev:/dev/sdb
# cat /run/lvm/pvs_online/5J3tM8aIPe2vbdDBe7bvRqTGj0DaKV2G
8:32
vg:vg
dev:/dev/sdc

so those files in /run/lvm/pvs_online/ are like little receipts, bestie. 🧾

🚀 Use of `-aay`

Now with -aay, it also autoactivates the VG when it becomes complete. First PV: incomplete. Second PV: complete and boom, LVs active.

# pvscan --cache -aay /dev/sdb
  pvscan[12935] PV /dev/sdb online, VG vg incomplete (need 1).
# pvscan --cache -aay /dev/sdc
  pvscan[12936] PV /dev/sdc online, VG vg is complete.
  pvscan[12936] VG vg run autoactivation.
  1 logical volume(s) in volume group "vg" now active

# cat /run/lvm/pvs_online/1uKpaTlFOZNLHXj4jIOBi1QpdEHZ5hZY
8:16
vg:vg
dev:/dev/sdb
# cat /run/lvm/pvs_online/5J3tM8aIPe2vbdDBe7bvRqTGj0DaKV2G
8:32
vg:vg
dev:/dev/sdc
# ls /run/lvm/vgs_online/vg
/run/lvm/vgs_online/vg

and there it is: /run/lvm/vgs_online/vg — that's the VG's online marker. periodt. 💅

📋 Use of `--listvg`

With --listvg, it just tells you which VG each PV belongs to. like a little name tag.

# pvscan --cache --listvg /dev/sdb
  VG vg
# pvscan --cache --listvg /dev/sdc
  VG vg

# cat /run/lvm/pvs_online/1uKpaTlFOZNLHXj4jIOBi1QpdEHZ5hZY
8:16
vg:vg
dev:/dev/sdb
# cat /run/lvm/pvs_online/5J3tM8aIPe2vbdDBe7bvRqTGj0DaKV2G
8:32
vg:vg
dev:/dev/sdc

no cap, it's that simple. ✨

✅ Use of `--checkcomplete`

Now --checkcomplete with --vgonline tells you if the VG is complete or not. so extra.

# pvscan --cache --listvg --checkcomplete --vgonline /dev/sdb
  pvscan[12996] PV /dev/sdb online, VG vg incomplete (need 1).
  VG vg incomplete
# pvscan --cache --listvg --checkcomplete --vgonline /dev/sdc
  pvscan[12997] PV /dev/sdc online, VG vg is complete.
  VG vg complete

it's giving "are we there yet?" but for volume groups. 😭

📢 Use of `--udevoutput`

Add --udevoutput and it spits out udev-friendly variables. super handy for rules.

# pvscan --cache --listvg --checkcomplete --vgonline --udevoutput /dev/sdb
LVM_VG_NAME_INCOMPLETE='vg'
# pvscan --cache --listvg --checkcomplete --vgonline --udevoutput /dev/sdc
LVM_VG_NAME_COMPLETE='vg'

look at those env vars! LVM_VG_NAME_INCOMPLETE and LVM_VG_NAME_COMPLETE. chef's kiss. 👨‍🍳💋

📦 Use of `--listlvs`

Finally, --listlvs shows you the LVs and whether they're complete. first, here's the LV layout:

# lvs -o name,devices vg
  LV    Devices
  lvol0 /dev/sdb(0)
  lvol1 /dev/sdc(0)
  lvol2 /dev/sdb(1),/dev/sdc(1)

then pvscan --cache --listlvs --checkcomplete on each PV:

# pvscan --cache --listlvs --checkcomplete /dev/sdb
  pvscan[13288] PV /dev/sdb online, VG vg incomplete (need 1).
  VG vg incomplete
  LV vg/lvol0 complete
  LV vg/lvol2 incomplete
# pvscan --cache --listlvs --checkcomplete /dev/sdc
  pvscan[13289] PV /dev/sdc online, VG vg is complete.
  VG vg complete
  LV vg/lvol1 complete
  LV vg/lvol2 complete

in the first command, lvol0 is complete and lvol2 is incomplete. in the second command, both are complete. slay. 🔥

👀 SEE ALSO

and that's a wrap, bestie! this page was brought to you by Red Hat, Inc. — LVM TOOLS version 2.03.44(2), dated 2026-10-27. this is LVMAUTOACTIVATION(7). stay iconic! 💖✨

📦 where this page comes from

arch rolling: lvm2 2.03.44-1 · GPL-2.0-only AND LGPL-2.1-only
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms

LVMAUTOACTIVATION(7)