The whole point of vgimportclone is to make the duplicate PV(s) and VG coexist with the originals.  As such it must cope with the fact that you have duplicate PV(s).

The vgimportclone shell script confines its operations to the PV(s) specified on the commandline by using a temporary lvm.conf.  It shouldn't see any other PV(s) other than those listed on the commandline.  No changes to the system's lvm.conf's filter config should have any bearing on how vgimportclone functions (since vgimportclone completely replaces the filter config with its own).

Also, the impact active LV(s) have on vgimportclone is in doubt in this BZ but we verify that an active LV doesn't negatively impact vgimportclone as part of the lvm2 testsuite.  This testsuite runs every time a change is committed for lvm2.

Please have the customer run vgimportclone with the --debug option.  This will preserve LVM_SYSTEM_DIR and the config that vgimportclone uses during runtime.
Please have them create a tarball of the /tmp/snap.XXXXXXX dir that is created, e.g.:
tar -cvzf /tmp/vgimportclone.tar.gz -C /tmp snap.qn1vLVIS

and have them provide /tmp/vgimportclone.tar.gz to us.

Created attachment 804161 [details]
vgimport clone default lvm filter

Created attachment 804163 [details]
vgimport clone modified lvm filter

Done some further testing.  Added -vvvv to cmd line to preserve the tmp config. The next step I did was to edit the file as follows to ensure the contents were not removed: 

    if [ $KEEP_TMP_LVM_SYSTEM_DIR -eq 1 ]; then
        echo "${SCRIPTNAME}: LVM_SYSTEM_DIR (${TMP_LVM_SYSTEM_DIR}) must be cleaned up manually."
    else
        echo "${TMP_LVM_SYSTEM_DIR}"   <<= Change this line to keep TMP contents
    fi
 

# LVM_BINARY=/usr/sbin/lvm vgimportclone --debug -vvvv --basevgname testrdmclone_vg02 /dev/sdc &> /tmp/cmd-output

However, the directory is empty:
# tar -cvzf /tmp/vgimportclone.tar.gz -C /tmp/snap.jBJ25334
tar: Cowardly refusing to create an empty archive

# ls -l /tmp/snap.jBJ25334/
total 0


One thing I noted is strange, which you can see in the attached cmd-output is that -vvvv is an argument, however it did not add any additional verbosity.

(In reply to Jon from comment #10)
> Done some further testing.  Added -vvvv to cmd line to preserve the tmp
> config. The next step I did was to edit the file as follows to ensure the
> contents were not removed: 
> 
>     if [ $KEEP_TMP_LVM_SYSTEM_DIR -eq 1 ]; then
>         echo "${SCRIPTNAME}: LVM_SYSTEM_DIR (${TMP_LVM_SYSTEM_DIR}) must be
> cleaned up manually."
>     else
>         echo "${TMP_LVM_SYSTEM_DIR}"   <<= Change this line to keep TMP
> contents
>     fi
>  
> 
> # LVM_BINARY=/usr/sbin/lvm vgimportclone --debug -vvvv --basevgname
> testrdmclone_vg02 /dev/sdc &> /tmp/cmd-output

The script isn't getting far enough to create the LVM_SYSTEM_DIR's lvm.conf because the pvs command doesn't think /dev/sdc is in a VG.

> However, the directory is empty:
> # tar -cvzf /tmp/vgimportclone.tar.gz -C /tmp/snap.jBJ25334
> tar: Cowardly refusing to create an empty archive
> 
> # ls -l /tmp/snap.jBJ25334/
> total 0
> 
> 
> One thing I noted is strange, which you can see in the attached cmd-output
> is that -vvvv is an argument, however it did not add any additional
> verbosity.

The additional output would've gone to stderr.

Created attachment 814777 [details]
pvs -vvvv output outside of vgimportclone

I fixed vgimportclone (upstream) to not redirect stderr to /dev/null for 3 of the lvm commands it runs, see:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=65456a4a29d8f25ab75af2145b8a6b2a9ff391e5

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.