Bug 1391090

(In reply to Nathaniel Weddle from comment #0)
> Description of problem:
> following successful vgexport of vg, vg-lv may be mounted manually, or will
> be mounted by fstab after reboot
> 
> Version-Release number of selected component (if applicable):
> RHEL7.0 to current release
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.vgchange -an myvg
> 2.vgexport myvg
> 3.mount myvg-lv /mnt/test

Was the deactivation successfully finish (return code 0) ?
No error reported.

Can you capture  'dmsetup table' before vgexport ?

It's for now  unclear how you would be able to mount  'inactive' LV ?

It works correctly for me with 7.2 and the latest code.  In addition to the commands that Zdenek suggested, I'd also run the following to ensure they are all reporting what we expect:

before vgexport:

vgchange -an myvg
vgs myvg
lvs myvg
ls /dev/myvg
dmsetup table

after vgexport:

ls /dev/myvg
dmsetup table
vgs myvg
lvs myvg
lvchange -ay myvg/lv

Zdenek, David,

I've attached my reproduction on this.  And here is the cli output:

Reproduction; use_lvmetad must be set to 1:
===========================================

[root@localhost ~]# lvs
  LV     VG     Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home   rhel   -wi-ao----    1.00g                                                    
  root   rhel   -wi-ao----    5.02g                                                    
  swap   rhel   -wi-ao---- 1000.00m                                                    
  testlv testvg -wi-ao---- 1020.00m     
                                               
[root@localhost ~]# umount /test1

[root@localhost ~]# vgchange -an testvg
  0 logical volume(s) in volume group "testvg" now active

[root@localhost ~]# vgexport testvg
  Volume group "testvg" successfully exported

......reboot.....

[root@localhost ~]# lvs
  Volume group testvg is exported
  LV   VG   Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home rhel -wi-ao----    1.00g                                                    
  root rhel -wi-ao----    5.02g                                                    
  swap rhel -wi-ao---- 1000.00m         

[root@localhost ~]# ls /dev/mapper | grep test
testvg-testlv

[root@localhost ~]# mount | grep test
/dev/mapper/testvg-testlv on /test1 type ext4 (rw,relatime,seclabel,data=ordered)

I will look further in the morning and provide the info you've requested.

Zdenek, David,
Had some extra time... Here is the info requested.

    [root@localhost ~]# umount /test1/
     
    [root@localhost ~]# vgchange -an testvg
      0 logical volume(s) in volume group "testvg" now active
     
    [root@localhost ~]# vgs testvg
      VG     #PV #LV #SN Attr   VSize    VFree
      testvg   1   1   0 wz--n- 1020.00m    0
     
    [root@localhost ~]# lvs testvg
      LV     VG     Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      testlv testvg -wi------- 1020.00m        
     
    [root@localhost ~]# ls /dev/testvg
    ls: cannot access /dev/testvg: No such file or directory
     
    [root@localhost ~]# dmsetup table
    rhel-home: 0 2097152 linear 252:2 10520576
    testvg-testlv: 0 2088960 linear 8:1 2048
    rhel-swap: 0 2048000 linear 252:2 12617728
    rhel-root: 0 10518528 linear 252:2 2048
     
    [root@localhost ~]# vgexport testvg
      Volume group "testvg" successfully exported
     
    [root@localhost ~]# echo $?
    0
     
    [root@localhost ~]# ls /dev/testvg
    ls: cannot access /dev/testvg: No such file or directory
     
    [root@localhost ~]# dmsetup table
    rhel-home: 0 2097152 linear 252:2 10520576
    rhel-swap: 0 2048000 linear 252:2 12617728
    rhel-root: 0 10518528 linear 252:2 2048
     
    [root@localhost ~]# vgs testvg
      VG     #PV #LV #SN Attr   VSize    VFree
      testvg   1   1   0 wzx-n- 1020.00m    0
     
    [root@localhost ~]# lvs testvg
      Volume group testvg is exported
     
    [root@localhost ~]# lvchange -ay testvg/testlv
      Volume group testvg is exported
     
    [root@localhost ~]# rpm -qa | egrep 'lvm*|udev*|device-mapper*|kernel*'
    device-mapper-multipath-0.4.9-85.el7_2.6.x86_64
    device-mapper-libs-1.02.107-5.el7_2.5.x86_64
    lvm2-libs-2.02.130-5.el7_2.5.x86_64
    device-mapper-persistent-data-0.6.2-1.el7_2.x86_64
    kernel-3.10.0-327.el7.x86_64
    device-mapper-multipath-libs-0.4.9-85.el7_2.6.x86_64
    libgudev1-219-19.el7_2.13.x86_64
    python-gudev-147.2-7.el7.x86_64
    device-mapper-1.02.107-5.el7_2.5.x86_64
    device-mapper-event-1.02.107-5.el7_2.5.x86_64
    kernel-tools-libs-3.10.0-327.36.3.el7.x86_64
    lvm2-2.02.130-5.el7_2.5.x86_64
    kernel-3.10.0-327.36.3.el7.x86_64
    python-pyudev-0.15-7.el7_2.1.noarch
    device-mapper-event-libs-1.02.107-5.el7_2.5.x86_64
    kernel-tools-3.10.0-327.36.3.el7.x86_64

Thanks, you're correct, I see the same here.  The 'pvscan --cache -aay' activation path is failing to respect the exported state of the VG.

fixed here
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=68e7d3496517a70e50edaceff906ad1da23821a6

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2222