Inventory Logical Volumes Safely with lvscan

Before you trust any capacity spreadsheet, run lvscan and see what LVM actually thinks exists on the box. You will finish with a repeatable way to list the logical volumes visible to LVM, choose readable or JSON output, and tell an empty result from a permissions or device-discovery problem. The commands here use the installed lvm2 package, version 2.03.16-3ubuntu3.2, whose tools report LVM version 2.03.16(2).

Allow about ten minutes. You need a shell and the LVM tools. The first checks are ordinary read-only commands. A complete inventory may need elevated privileges because LVM must inspect block devices and acquire its normal locks. This guide does not create, activate, resize, remove or otherwise alter a logical volume.

1. Confirm the Installed Command

Check which executable will run and record the package version. These commands do not change storage:

$ command -v lvscan
/usr/sbin/lvscan
$ dpkg-query -W -f='${Package} ${Version}\n' lvm2
lvm2 2.03.16-3ubuntu3.2
$ lvscan --version
  LVM version:     2.03.16(2) (2022-05-18)

The exact library and build lines can differ between distributions. If your version is newer, read its local help before copying an option from another host. The installed command accepts --all, --readonly and --reportformat basic|json, along with common LVM options.

Checkpoint: you know the binary and package version. If command -v finds a wrapper or a different path, stop and establish which installation you intend to inspect.

2. Run the Normal Inventory

Start with the default report:

$ lvscan
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.

On a machine where LVM can see its devices, the report contains one line for each logical volume, showing whether it is active, whether it is a snapshot or origin, its size and its allocation policy. The line format and the number of rows depend on the host, its metadata and the LVM configuration.

On this unprivileged test shell the command emitted a warning and no LV rows. That is not proof the machine has no logical volumes; run the same check with the privileges appropriate to your host:

$ sudo lvscan

sudo is only needed when your account cannot inspect the relevant devices or locks. It does not make a missing or deliberately restricted device visible. Review the command output and exit status before investigating further.

3. Prefer Read-Only Mode for Inspection

Use --readonly when you want LVM to read on-disk metadata without needing its normal locks. This is especially useful when examining metadata associated with a virtual machine image while the machine is running:

$ sudo lvscan --readonly

This mode does not communicate with the device-mapper kernel driver, so it cannot report whether an LV is actually in use. A read-only scan is a metadata inventory, not a live-use check. If you need active-state information, compare it with a normal scan performed under the host's approved maintenance and access conditions.

Safety boundary: --readonly is an inspection choice, not a backup and not a guarantee that every underlying device is safe to access. Do not point LVM tools at a live image or an unfamiliar device until you have confirmed the image and its ownership.

4. Produce JSON for a Script

For automation, request the report format explicitly and keep the command's exit status:

$ lvscan --readonly --reportformat json
{
}
$ status=$?
$ printf 'lvscan exit status: %s\n' "$status"
lvscan exit status: 0

The exact JSON report includes rows when visible logical volumes exist. On this host's unprivileged probe, the installed command printed an empty JSON object rather than LV rows, so the output is host-specific: do not write a parser that assumes an LV is present.

Scripts should check the exit status and validate the JSON structure. A successful command can still describe an empty inventory. Treat a non-zero status, stderr diagnostics or malformed JSON as an operational error rather than silently reporting zero volumes.

5. Include Internal LVs Only When Needed

Normal output omits internal logical volumes, which are components of ordinary LVs and are not independently accessible. Add --all when you are diagnosing an LVM layout and need those components included:

$ sudo lvscan --all --readonly
$ sudo lvscan --all --readonly --reportformat json

Expect more rows than a normal inventory on hosts using mirrors or other layered layouts. Internal objects are implementation details, not extra mountable filesystems: avoid feeding them into a capacity or mount report without identifying their role.

Common traps

Work through these checks in order so a distraction does not turn into a storage change:

  1. Confirm the help matches the version. Run lvscan --help and check the options belong to the installed version.
  2. Repeat with the right privilege. Compare stderr and the exit status between runs.
  3. Check the physical devices. Confirm the intended devices are attached and visible to the operating system.
  4. Review filtering. Check LVM device filtering and any devices file if the host uses restricted discovery.
  5. Use --devices PV sparingly. Only with an explicit, verified device path or paths to inspect.

The --devices option restricts what the command can see. A device excluded by that option appears to be missing, so a narrow scan can create a misleadingly empty result. The option can be repeated or given a comma-separated list. Do not guess device names, and do not add --nolocking merely to silence a lock error: the manual warns that concurrent commands can then produce incorrect results.

For more detail, use --verbose or --debug. These options report more information; they do not repair metadata, activate devices or change configuration. If a scan reports damaged or missing metadata, stop before using repair or restoration commands: those are separate, potentially destructive operations.

Done means