Bug 681541

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This looks like a problem in something different. Both my tests are working as expected and system-config-lvm is working. 

Unit test for missing PV:

dd if=/dev/zero of=loopA count=30000 bs=1024
dd if=/dev/zero of=loopB count=30000 bs=1024

losetup -f loop; pvcreate /dev/loop0 /dev/loop1;
vgcreate foo /dev/loop0; lvcreate foo -n goo -l 10%FREE
losetup -d /dev/loop1
run system-config-lvm

Unit test for duplicate PV:

dd if=/dev/zero of=loopA count=30000 bs=1024
losetup -f loopA
pvcreate /dev/loop0
vgcreate foo /dev/loop0
lvcreate -n hugo foo -l 10%FREE
vgchange -an foo
cp loopA loopB
losetup -f loopB
pvscan
run system-config-lvm

Indeed, the situation I experienced was different.

(I'll try to reproduce it exactly). I my case the problem is that the host OS is seeing the virtual VG that are within a VM.

Here are the bigger step to reproduce : 

- Install a RHEL with Virtualization Tools (leave some place in the VG ideally)
- Create a VG and carve a LV from it.
- Set this LV to be the storage of a Virtual Machine (I used KVM)
- Boot the VM and at install set a standard LVM layer.

When using pvscan (or vgscan) the host server see the VG of the guest, but apparently can't see the PV.

Please, note that the VG I created for the VMs are located on iSCSI storage

I believe I could exactly reproduce the setup, I'll post it here.

Bruno

Another possibility is that the bug is due to PV nesting within LVs. There is only limited support for this scenario and it is strongly suggested to use lvm.conf device filters to avoid this whenever possible. (You should exclude any LVs you have from LVM PV scanning. The documentation and examples in your lvm.conf should give you enough guidance.) This is especially true when you are dealing with virtual machine images.

Hi,

Here is my filter from lvm.conf : 

filter = [ "a|/dev/sda2|","a|/dev/mapper/.*|", "r|.*|" ] 

The /dev/sda2 is the main storage for local installation, all others disks are connected through iSCSI and multi-pathed.

I noticed something while analysing the missings PV. It appears only when the virtual machine is using two PV grouped together within one VG. It is usually a scenario when you want to increase the size of the storage for the vm, and you add a second PV, then group ip within a VG (then resize the fs).

Bruno

Hi Bruno,

From looking at your filter (I assume this is in the host, not the guest right?), and your .cache file:
filter = [ "a|/dev/sda2|","a|/dev/mapper/.*|", "r|.*|" ] 

It seems clear the filter will allow the host to scan the logical volumes which were assigned to the guest (The 'a|/dev/mapper/.*|' part will pick up all the multipath paths, as well as logical volumes).  Since this is allowed, these logical volumes will be seen as "PVs" as well, since they've been exported to the guest, and inside the guest they were initialized as PVs.  I don't think this is what you intend.

To avoid this you should set the filter more restrictively, so that the logical volumes exported to the guest are not scanned by any lvm commands in the host.

To see which devices lvm commands will scan, look at the contents of the /etc/lvm/cache/.cache file.  If it contains any of the logical volumes exported to the hosts, it probably needs adjusted.  One common adjustment is as follows:
For multipath LUNs using user_friendly_names, add
"a|/dev/mapper/mpath.*|" instead of
"a|/dev/mapper/.*|"

You should probably look at https://access.redhat.com/kb/docs/DOC-2991 for configuration of the filter properly.

Even still, this should not cause system-config-lvm to crash.

Hi Dave,

I agree the filter should be set more restrictively but I don't use friendly names in the multipath configuration, so I can't use "a|/dev/mapper/mpath.*|", but I could even be explicit by defining each multipath volume like this : 

filter = [ "a|/dev/sda2|",
           "a|/dev/mapper/alias1|",
           "a|/dev/mapper/alias2|", "r|.*|" ] 

I guess it would not really impact the performance of the scanning since it is done only once at a time.

Bruno

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.