"Found duplicate PV"

Question

SERVER:~ # pvs
  Found duplicate PV Wb0b2UTCKtpUtSki0k2NnIB24qNj4CEP: using /dev/mapper/36005076304ffc2500000000000004903 not /dev/mapper/36005076304ffc2990000000000004903
  PV                                            VG          Fmt  Attr PSize   PFree  
  /dev/mapper/36005076304ffc2500000000000004903 application lvm2 a--   50.00g  35.00g
  /dev/sda4                                     system      lvm2 a--  133.24g 100.39g
SERVER:~ # 

OS is a SLES 11 SP3.

Question: Could this be a problem? If yes, how to solve the duplicate PV message? :) The disks are coming from SAN/multipath.

Solution

In my personal experience, "duplicate PV" is usually caused by the system having multipath access to a particular SAN LUN but LVM hasn't been configured to filter out the block devices for the individual paths. The device mapper name even looks like a WWNN/WWPN (although I don't have enough experience with SLES to know if that could be something else). Not sure why a PV would itself be served out of a DM device, though.

In RHEL I would look in /dev/disk/by-path and see if these are the same LUN's.

Could this be a problem?

If you're supposed to be on a multipath setup it could be an issue. For example if the underlying device is supposed to be /dev/mapper/mpathf but LVM found /dev/sdf first and decided to activate that, then your access to storage isn't as redundant as you were spec'd out to be. For example if the path /dev/sdf goes down the VG and all its LV's could become inaccessible.

If yes, how to solve the duplicate PV message?

With LVM, each PV has an "LVM header" that tells you the UUID of this PV, the name of the VG it's in, and the UUID's of all the other PV's in the same VG (which is how it can tell if there's a missing PV). All this error means is that it found another PV out there that had the same UUID.

So there isn't really a single cause for this so it's hard to propose a solution with the information you've provided.

It sounds like your lvm.conf just needs its filter set up to ignore the individual paths (as stated earlier) but you'd have to do more research to confirm that since that's pretty much a WAG (wild-ass guess).

For an example of an lvm filter:

filter = [ "r/block/", "r/disk/", "r/sd.*/", "a/.*/" ]

The above filter skips ("removes") any device with the words "block" or "disk" in the name. It also removes any device that begins with "sd" (such as sdf, sdg, etc, etc) and finally "allows" all other devices (".*").

You probably don't want to go that far though (since you use /dev/sda4 for the root VG). I would just remove the specific block devices that are for the individual paths.

But again, verify. It could be a million other things too (SAN Admin cloned a LUN and presented it to your system for some reason, unlikely random collision between UUID's, cosmic rays, bad luck, etc).

UPDATE:

I should also mention that any time you update /etc/lvm/lvm.conf (RHEL path) you should rebuild any initramfs you have. It looks like you're using these as storage outside the root VG (which is best practice) but any time you modify that file you should make sure the kernel sees the same file at boot as it does thereafter just so you get consistent results.