Bug 1012161
Summary: | vgimportclone fails due to duplicate PV | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Jon Magrini <jmagrini> | ||||||
Component: | lvm2 | Assignee: | Peter Rajnoha <prajnoha> | ||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Cluster QE <mspqa-list> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 5.7 | CC: | agk, cmarthal, dwysocha, heinzm, jbrassow, jekirkpa, jmagrini, jwaterwo, lmiksik, msnitzer, prajnoha, prockai, thornber, zkabelac | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | 697959 | Environment: | |||||||
Last Closed: | 2014-07-30 07:48:23 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1049888 | ||||||||
Attachments: |
|
Description
Jon Magrini
2013-09-25 20:53:11 UTC
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. |