LVM Found duplicate PV: multipath devices and the lvm.conf filter

When LVM prints “Found duplicate PV” during boot or routine commands, it has found the same PV UUID on two or more block devices. On multipath-attached storage, this almost always means LVM is scanning both the raw SCSI paths (/dev/sdb, /dev/sdc) and the aggregated multipath device (/dev/mapper/mpatha). Each path carries the same PV metadata header.

The warning is advisory at first: LVM picks one device and proceeds. The danger is which one. If LVM activates a logical volume through a raw path instead of the multipath device, you lose path redundancy and failover. I/O runs through a single HBA link until that link fails, then the volume goes dark. The system can boot fine for weeks until a udev timing race changes which device LVM selects, and the next path failure takes down production.

The fix is the device filter in /etc/lvm/lvm.conf: accept multipath devices, reject raw paths, then rebuild the initramfs so the filter survives reboot.

What this means

LVM identifies physical volumes by UUID, not device path. When it scans block devices and finds the same PV UUID on both /dev/sdb and /dev/mapper/mpatha, it cannot reliably determine which is the correct access path. The metadata on both is identical because multipath presents the same LUN through multiple physical paths.

flowchart TD
    LUN[SAN LUN with PV metadata]
    LUN --> R1[raw path /dev/sdb]
    LUN --> R2[raw path /dev/sdc]
    R1 --> MP[multipath /dev/mapper/mpatha]
    R2 --> MP
    SCAN[LVM scan with default filter]
    R1 -.->|PV UUID found| SCAN
    MP -.->|PV UUID found| SCAN
    SCAN --> WARN[Found duplicate PV warning]

With the default filter (filter = [ "a/.*/" ], which accepts all block devices), LVM scans every /dev/sd* path plus every /dev/mapper/mpath* device. It finds the PV UUID multiple times and prints the warning. It then selects one device, typically the first one scanned, which may be a raw path rather than the multipath device.

The consequence is silent. No error in dmesg, no application failure, no obvious metric spike. The LV activates and serves I/O through a single path. You discover the problem only when that path fails or when you run multipath -ll and notice LVM is not using the multipath device.

In the worst case, LVM refuses to operate at all. When duplicate PVs are detected and resolution is ambiguous, LVM may print “Cannot activate LVs in VG while PVs appear on duplicate devices” and refuse to activate any LV in the affected volume group. This is a hard failure, not just a warning.

Common causes

Quick checks

Run these read-only commands to confirm the problem and gather context:

# Show all PVs and look for duplicate entries (same VG, same size)
pvs -o pv_name,vg_name,pv_attr,pv_size,pv_free

# Show multipath topology and verify which paths exist
multipath -ll

# List block devices and their relationships
lsblk -o NAME,TYPE,SIZE,MOUNTPOINT

# Check the current device filter in lvm.conf
grep -E 'filter|global_filter' /etc/lvm/lvm.conf

# Check if multipath_component_detection is enabled
grep multipath_component_detection /etc/lvm/lvm.conf

# Look for the duplicate PV warning in recent boot logs
journalctl -b 0 | grep -i 'duplicate PV'

# Verify which device LVM actually selected for the PV
pvdisplay --columns 2>/dev/null | head -20

How to diagnose it

1. Identify the duplicate devices. The warning message names both devices. Example: “Found duplicate PV DevUIu3DYC2V4Wc2Lb6H8dGfH1oH8Fj0Zm3bNiLmOvPq1Rs2Tu3: using /dev/mapper/mpatha not /dev/sdb.” The first device listed is the one LVM chose. If it chose a raw path (/dev/sdb), your LV is running without multipath redundancy.

2. Verify multipath topology. Run multipath -ll to see the device tree. Confirm that /dev/mapper/mpatha is the multipath device aggregating the raw paths. If multipath is not running or the device does not appear, fix multipath first. LVM cannot use a multipath device that does not exist.

3. Check the current filter. Run grep filter /etc/lvm/lvm.conf. If the output shows filter = [ "a/.*/" ] or no filter at all, LVM is scanning everything by default. This is the root cause on most systems.

4. Test a candidate filter before applying it. Use the --config override to test without modifying the config file:

# Test: accept only multipath devices, reject everything else
lvs --config 'devices{ filter = [ "a|/dev/mapper/mpath.*|", "r|.*|" ] }'

If this command returns your LVs without the duplicate PV warning, the filter is correct. If it returns nothing, the filter is too restrictive and you need to also accept the boot device or root VG device.

5. Check for the boot race. Look at the journal timeline:

# Did LVM scan before multipath claimed the devices?
journalctl -b 0 | grep -E 'duplicate PV|multipath|pvscan' | head -30

If pvscan runs before multipathd has created /dev/mapper/mpatha, LVM sees only the raw paths and has no multipath device to prefer. An explicit filter that rejects raw paths prevents LVM from ever scanning them, regardless of boot ordering.

Metrics and signals to monitor

Fixes

Configure the lvm.conf filter for multipath

This is the standard fix when one or both duplicate devices are paths to the same multipath LUN (the first two rows of the common causes table).

The filter syntax uses a for accept and r for reject, with regex patterns between pipe delimiters. Rules are evaluated in order, first match wins. Any device not matched by a rule is rejected by default, so include a catch-all a/.*/ as the final rule.

Edit /etc/lvm/lvm.conf and set both filter and global_filter:

# Accept multipath devices, reject raw SCSI paths, accept everything else
global_filter = [ "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ]
filter = [ "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ]

The r|/dev/sd.*| pattern matches only /dev/sd* devices (SATA, SCSI, SAS). NVMe devices use /dev/nvme* naming and are not affected. However, local SATA/SCSI disks are also rejected, so an explicit accept rule for boot or root devices is required.

If your boot or root filesystem is on a local disk (not behind multipath), add an explicit accept rule for it before the reject:

global_filter = [ "a|/dev/sda2$|", "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ]
filter = [ "a|/dev/sda2$|", "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ]

On RHEL 8 and later, prefer persistent identifiers (WWID) over kernel device names, which can shift across reboots:

global_filter = [ "a|/dev/disk/by-id/<disk-id>.*|", "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ]

Why both filter and global_filter? On legacy systems with lvmetad (removed in LVM2 2.03; no longer present in RHEL 8), the filter setting did not apply to pvscan during early boot. You needed global_filter for udev and boot-time scanning. On modern systems without lvmetad, the distinction matters less, but global_filter is still the correct setting for system-wide device filtering that covers udev rules and early boot activation. Setting both to the same value is the safe approach.

After editing, test the filter non-destructively:

# Verify no duplicate PV warnings and all expected LVs are visible
lvs --config 'devices{ filter = [ "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ] }'
pvs --config 'devices{ filter = [ "a|/dev/mapper/mpath.*|", "r|/dev/sd.*|", "a/.*/" ] }'

Then rebuild the initramfs so the filter takes effect at boot:

# RHEL, CentOS, Fedora
dracut -f -v

# Debian, Ubuntu
update-initramfs -u

Without rebuilding the initramfs, the old filter persists in the boot image and the duplicate PV warning reappears on the next reboot.

After reboot, verify the fix:

# Should show no duplicate PV warnings
journalctl -b 0 | grep -i 'duplicate PV'

# Confirm LVM is using the multipath device
pvs -o pv_name,vg_name

Why multipath_component_detection is not enough. LVM has a setting multipath_component_detection = 1 that tells it to skip devices that appear to be multipath components. This does not reliably prevent duplicate PV warnings because of a boot race: if LVM scans the raw /dev/sd* paths before multipathd has claimed them, LVM opens them and sees the PV. Multipath cannot claim a device that LVM has already opened. An explicit filter that rejects raw paths is the only reliable fix.

Handle SAN LUN clones (both devices are multipath maps)

If the duplicate PV warning names two multipath devices (for example, /dev/mapper/mpatha vs /dev/mapper/mpathc), the SAN has presented the same LUN twice as separate devices. This is not a filter problem. The storage array has created a LUN clone or mirror and presented it to the host.

A filter cannot resolve this because both devices are legitimate multipath devices. You need to work with your storage team to either remove the clone from the host’s LUN masking or change one of the PV UUIDs if the clone is intentional.

Handle non-multipath duplicate PVs (VM clones)

If you cloned a VM disk and both the original and clone are visible to the same host, LVM sees the same PV UUID on two devices. The pvs output shows a duplicate indicator in the attribute column.

If the clone is a separate machine that should have its own PV identity, regenerate the UUID:

# WARNING: changes the PV UUID. Run only on the cloned disk, never the original.
pvchange --uuid /dev/sdX

If you are importing a cloned VG into the same host intentionally, use vgimportclone, which handles UUID regeneration for all PVs in the VG:

# Import a cloned VG with new UUIDs
vgimportclone /dev/sdX

Prevention

• Set the filter during provisioning. Configure the multipath filter before the host goes into production, not after the warning appears. Bake it into imaging or configuration management templates.
• Use persistent device names. On RHEL 8+, use WWID-based filters (/dev/disk/by-id/) instead of kernel names (/dev/sdX). Kernel names can shift when disks are added or removed.
• Audit the filter on every multipath host. Add grep global_filter /etc/lvm/lvm.conf to your host validation checklist. Every multipath host should reject raw paths in its filter.
• Rebuild the initramfs after every filter change. This is the most commonly missed step. The running config and the initramfs config are independent. A filter change without a rebuild silently fails on the next reboot.
• Test after storage stack updates. Kernel updates, multipath package upgrades, and SAN firmware changes can alter boot timing and device enumeration order. Re-verify that no duplicate PV warnings appear after any storage stack change.

How Netdata helps

Correlating these signals shortens diagnosis when LVM is using the wrong device path:

• Per-second disk I/O metrics per device. If I/O appears on /dev/sdb instead of /dev/mapper/mpatha, Netdata’s disk charts make the mismatch visible immediately.
• Block device error rates. When LVM is using a raw path and that path fails, block device error counters spike. Netdata correlates this with the PV going missing.
• Kernel log integration. The “Found duplicate PV” warning and multipath path failover messages appear in the same timeline as disk I/O and LVM state changes, making the boot race pattern obvious.
• D-state process detection. If a raw path fails while LVM is using it, processes doing I/O to the affected LV enter uninterruptible sleep. Netdata surfaces process state changes alongside the storage metrics.

Related guides

• LVM cannot extend a logical volume: adding a PV when the VG is full
• LVM Couldn’t find device with uuid: a physical volume has gone missing
• LVM filesystem full while the volume group has space: the resize step everyone forgets
• How LVM actually works in production: a mental model for operators
• LVM Insufficient free extents: the volume group is out of space
• LVM monitoring checklist: the signals every production volume manager needs
• LVM monitoring maturity model: from survival to expert
• LVM reached low water mark for data device: the thin pool warning before the freeze
• LVM thin pool space not reclaimed: discard, TRIM, and fstrim
• LVM snapshot COW usage climbing: extend or remove before it overflows
• LVM snapshot invalid: the COW exception store filled and the snapshot is gone
• LVM snapshot slowing the origin: copy-on-write write amplification