Find LVM Physical Volumes Safely with lvmdiskscan

You will use lvmdiskscan to see which disks and partitions the local LVM tools recognise as possible physical volumes (PVs), then narrow the check to a known device without changing storage. The command is read-oriented, but it still inspects real block devices, so run it deliberately on a production host.

Allow about 10 minutes if LVM is already installed and you only need an inventory. You need the lvm2 package and, in practice, elevated privileges to avoid incomplete device access. The examples below were checked against LVM 2.03.16(2), released with the local manpage on 18 May 2022. Your output will differ with the host's disks and LVM configuration.

Checkpoint: know what the command does

lvmdiskscan scans SCSI, IDE, multipath and other block devices looking for LVM PVs. It reports the real size of each device it examines. It does not create a PV, alter a partition table, mount a filesystem or activate a logical volume.

The command is deprecated. For a current inventory of PVs that LVM already knows about, prefer pvs. lvmdiskscan remains useful when you specifically want a broad scan of candidate devices, including devices that are not yet part of an LVM volume group.

Its name can cause a second misunderstanding: a device reported by the broad scan is not automatically safe to initialise. Treat every reported disk as potentially containing data until you have identified it by stable path, serial number and intended role.

1. Check the installed version

This is an ordinary read-only command. It may print warnings if the process cannot talk to device-mapper, but the version line is still useful for matching local behaviour to documentation.

lvmdiskscan --version

On the system used for this guide, the relevant lines include:

LVM version:     2.03.16(2) (2022-05-18)
Library version: 1.02.185 (2022-05-18)

Do not copy a warning-free result from another machine as an expectation. LVM may also report the kernel device-mapper version and build configuration.

2. Run a broad scan

Use sudo for the real host inventory. No metadata is written by this command, and there is no confirmation prompt to approve.

sudo lvmdiskscan

A host with no visible disks might produce a result shaped like this:

  0 disks
  0 partitions
  0 LVM physical volume whole disks
  0 LVM physical volumes

On a populated system, the scan adds device lines and counts. The exact labels and sizes are discovered output, not values to predict. Capture the command's exit status when using it in a script:

if sudo lvmdiskscan >/tmp/lvmdiskscan.txt 2>&1; then
    sed -n '1,120p' /tmp/lvmdiskscan.txt
else
    printf '%s\n' 'lvmdiskscan failed; inspect its diagnostics' >&2
    exit 1
fi

The temporary file is only a transcript. Remove it when it is no longer needed:

rm -- /tmp/lvmdiskscan.txt

3. Show only LVM physical volumes

Add --lvmpartition when you do not want the general disk and partition inventory. This mode restricts the report to devices LVM identifies as PVs.

sudo lvmdiskscan --lvmpartition

The output ends with counts for whole-disk PVs and all detected PVs. If it shows zero PVs, that can mean there are none, the relevant device is not visible to this process, or the LVM device filter excluded it. It is not proof that a blank-looking disk is safe to overwrite.

4. Limit the scan to a known device

Use --devices to restrict what the command can see. The argument is a physical volume path or a comma-separated list, and the option can be repeated. This is useful when a host has removable media or many unrelated devices.

sudo lvmdiskscan --devices /dev/mapper/example-pv

Replace the placeholder with a path you have already verified. For example, inspect the device identity before scanning:

lsblk --output NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MODEL,SERIAL
sudo lvmdiskscan --devices /dev/sdb

A restricted scan can report a device as missing if the path is wrong or the current LVM devices file excludes it. That is a visibility result, not a filesystem diagnosis. The --devices argument overrides the devices file for this invocation.

5. Choose a read-only inspection mode when needed

--readonly tells LVM to read on-disk metadata without taking locks. The manpage describes this as useful for peeking inside metadata used by a virtual machine image while the virtual machine is running. It also prevents communication with the device-mapper kernel driver, so it cannot tell you whether logical volumes are in use.

sudo lvmdiskscan --readonly --devices /dev/sdb

This option is not a magic bypass for permissions or damaged media. It changes the inspection mode, not the identity of the device, and its result is deliberately less complete about active logical volumes.

Common traps and safe recovery

• Running without privilege: the command can warn that functionality may be unavailable and return an empty inventory. Retry with sudo before concluding that no devices exist.
• Confusing a PV with a whole disk: a PV may be a partition, a whole disk, a multipath device or another block device. Confirm the path with lsblk and your storage records.
• Ignoring the LVM filter: the manpage recommends using the filter in /etc/lvm/lvm.conf to avoid devices such as a CD-ROM. Read the current configuration before changing it. A filter change can affect later LVM commands, so do not edit it merely to make one scan look complete.
• Using --nolocking casually: this disables locking and can let concurrent commands produce incorrect results. It is not a normal troubleshooting switch.
• Adding --yes out of habit: it assumes yes to prompts. This scan does not need it, and it is a dangerous habit to carry into commands that change metadata.

Nothing in the examples changes storage state, so there is no rollback operation. If you later use a separate command such as pvcreate, stop and verify the device again first. That is a metadata-writing operation and may destroy existing signatures or make existing data inaccessible.

When to use pvs instead

For routine administration, start with:

sudo pvs

Use it to inspect PVs already known to LVM, then use lvmdiskscan when the specific question is "which visible block devices might contain PV metadata?" This distinction avoids treating a broad candidate scan as an authoritative inventory.

Done means

• You recorded the local LVM version and any device-access warnings.
• You ran the broad scan with the privileges needed for the host.
• You used --lvmpartition or --devices when a narrower result was safer.
• You verified every candidate path with independent device information before any future write operation.
• You know that pvs is the preferred command for the current PV inventory.