Find LVM Physical Volumes and Refresh Device State with pvscan

pvscan does two very different jobs depending on one flag: list physical volumes, or rewrite LVM's runtime record of what is currently online. The examples match LVM 2.03.16(2), installed here from package lvm2 version 2.03.16-3ubuntu3.2.

Allow about ten minutes. You need a shell and LVM2.
Listing is normally read-only, though device visibility and locking policy can affect the result.
The --cache examples change runtime LVM state and may auto-activate logical volumes, so treat them as operational commands and run them with elevated privileges when your host requires it.

1. Confirm the installed command

Check the binary and version first. This is an ordinary command:

$ command -v pvscan
/usr/sbin/pvscan
$ pvscan --version
  LVM version:     2.03.16(2) (2022-05-18)

The library and build details may vary. The version matters because pvscan has two distinct jobs in this LVM release: without --cache it reports PVs, with --cache it updates runtime device state.

Checkpoint: if command -v pvscan returns nothing, install the distribution's LVM2 utilities before continuing. Do not copy a command from another host and assume its options are identical.

2. List all visible physical volumes

Run the default scan first:

$ pvscan
  PV /dev/mapper/example-pv   VG data   lvm2 [100.00 GiB / 20.00 GiB free]
  Total: 1 [100.00 GiB] / in use: 1 [100.00 GiB] / in no VG: 0 [0   ]

The paths and sizes above are representative; your output will only contain PVs visible to this host. An empty result such as No matching physical volumes found can mean there are no LVM PVs, the device is not visible to LVM, or the command cannot get the locks or device access it needs. It is not proof a disk contains no data.

On this machine, the non-root command also warns when it cannot open the LVM lock or device-mapper control path. If you are checking a host where LVM access is restricted, repeat the same read-only query with privilege:

$ sudo pvscan
# output depends on the host's PVs

Only reach for sudo on this diagnostic when the first run reported a permission or locking problem. Do not work around a locking error with --nolocking during normal administration: the manpage warns that concurrent commands can then produce incorrect results.

3. Choose a useful listing format

Keep the default output for a quick human check, or pick one of the focused forms:

$ pvscan --short
$ pvscan --uuid
$ pvscan --novolumegroup
$ pvscan --reportformat json

--short requests a shorter listing.
--uuid adds PV UUIDs, useful when device names can change.
--novolumegroup limits the report to PVs that do not belong to a VG.
--reportformat json requests JSON instead of the original column-and-row format; use it when another program consumes the report.

Check the output format before writing a parser. On a host with no matching PVs, the installed command can produce an empty JSON object rather than a list with a zero count, so a script should validate the exit status and the report shape it actually receives.

Checkpoint: save a diagnostic snapshot without changing state:

$ pvscan --reportformat json > pvscan-report.json
$ test -s pvscan-report.json && sed -n '1,12p' pvscan-report.json

The redirection creates or replaces pvscan-report.json in the current directory. Choose a deliberate path first if that matters. The file is only a report and can be removed afterwards with rm -- pvscan-report.json, which does not alter LVM.

4. Check which VG or LV uses one PV

Once you have an exact device path, ask pvscan about its relationships. Replace the placeholder with a real PV path from your own scan:

$ PV_DEVICE=/dev/EXAMPLE_PV
$ pvscan --listvg "$PV_DEVICE"
data
$ pvscan --listlvs "$PV_DEVICE"
data-root
data-home

--listvg prints the VG using the PV; --listlvs prints the LVs using it. The output is host-specific and can be empty if the device is not a PV or is not currently visible. Neither command activates, deactivates, resizes or removes anything.

Do not infer completeness from the presence of one PV. For a multi-device VG, use the event-oriented form in the next step when a device has just appeared.

5. Refresh runtime state for a device

--cache changes what LVM records as online. With a present device, the command records its PV as online; if the named device is absent, LVM removes that online record. It scans only the named device:

$ sudo pvscan --cache /dev/EXAMPLE_PV

This is not a metadata repair command and it does not create a PV. It updates runtime state used by LVM's event-based device handling. The device path must identify the PV you intend to process.

To refresh all LVM devices instead, omit the device argument:

$ sudo pvscan --cache

Checkpoint: run a normal listing afterwards and compare it with the pre-change report:

$ sudo pvscan
$ sudo pvscan --listvg /dev/EXAMPLE_PV

Recovery: for an ordinary cache refresh, run sudo pvscan --cache again after correcting the device visibility problem, or process the specific device that should be online. There is no separate undo command, because this state simply reflects which devices LVM can currently see.

6. Understand autoactivation before using it

The -aay form combines the cache update with a completeness check. When all PVs for a VG are online, it can auto-activate the LVs in that VG, similar to vgchange -aay VG_NAME:

$ sudo pvscan --cache -aay /dev/EXAMPLE_PV

With no device argument, it processes all devices and auto-activates any complete VGs:

$ sudo pvscan --cache -aay

Warning: these commands can create device-mapper nodes and make storage available to services. That is a service-affecting change, not merely a report. Before using them, confirm the expected VG, the host's autoactivation policy, and that no maintenance operation is intentionally keeping the VG inactive. If you activate the wrong VG, stop the dependent service and use the documented LVM control for that environment, such as vgchange -an VG_NAME, only after checking that no filesystem is mounted or in use. Deactivating an in-use LV can cause data loss.

Common traps

No PVs found. Check the device path, permissions, LVM device filtering, and whether the storage has actually arrived. A scan only sees devices allowed by the current LVM configuration.
A VG looks incomplete. Use pvscan --cache --listvg --checkcomplete /dev/EXAMPLE_PV to ask LVM whether all devices for the listed VG are online. Expect complete or incomplete alongside the listed object where applicable.
A script gets noisy output. Use --quiet only after you have decided which output and exit status the script needs. Do not parse warnings as PV data.
Udev is involved. Leave udev synchronisation enabled unless you know the host has no running udev or has rules that ignore LVM-created devices. --noudevsync deliberately stops waiting for udev notifications.

Done means

Version and mode clear: you confirmed the installed LVM version and can tell a report apart from a cache update.
Listing checked: you ran pvscan and, where useful, checked UUID, JSON, ungrouped, VG or LV output.
Cache used deliberately: --cache only ran against an identified device or a deliberate all-device refresh.
Activation respected: you treated -aay as an activation change and checked the VG before letting services use it.