Bug 483583 - RFE: allow the ability to stack pvs on top of existing origins (with snaps)
RFE: allow the ability to stack pvs on top of existing origins (with snaps)
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2009-02-02 10:13 EST by Corey Marthaler
Modified: 2010-11-01 07:32 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-10-31 23:39:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2009-02-02 10:13:10 EST
Description of problem:
This is likely the same issue as bug 481384.

[root@hayes-03 cache]# lvs -a -o +devices
  LV       VG         Attr   LSize   Origin  Snap%  Move Log Copy%  Convert Devices               
  origin1  base1      owi-a- 100.00M                                        /dev/etherd/e1.1p1(0) 
  snap1    base1      swi-a-  12.00M origin1   0.13                         /dev/etherd/e1.1p1(25)
  origin2  base2      owi-a- 100.00M                                        /dev/etherd/e1.1p2(0) 
  snap2    base2      swi-a-  12.00M origin2   0.13                         /dev/etherd/e1.1p2(25)

[root@hayes-03 cache]# pvcreate /dev/base1/origin1 
  Physical volume "/dev/base1/origin1" successfully created
[root@hayes-03 cache]# pvcreate /dev/base2/origin2
  Physical volume "/dev/base2/origin2" successfully created

[root@hayes-03 cache]# pvscan
  Found duplicate PV F4qW107N5AhBuGaVkFRgLFYCbjhEf7Ms: using /dev/mapper/base1-origin1-real not /dev/base1/origin1
  Found duplicate PV rh9vKtdPUAcItGPnmI7OyNdopfI2WSpi: using /dev/mapper/base2-origin2-real not /dev/base2/origin2
  PV /dev/etherd/e1.1p2               VG base2           lvm2 [1.77 TB / 1.77 TB free]
  PV /dev/etherd/e1.1p1               VG base1           lvm2 [1.77 TB / 1.77 TB free]
  PV /dev/sda2                        VG VolGroup00      lvm2 [74.38 GB / 0    free]
  PV /dev/mapper/base1-origin1-real                      lvm2 [100.00 MB]
  PV /dev/mapper/base2-origin2-real                      lvm2 [100.00 MB]
  PV /dev/etherd/e1.1p3                                  lvm2 [1.77 TB]
  PV /dev/etherd/e1.1p4                                  lvm2 [1.77 TB]
  PV /dev/etherd/e1.1p5                                  lvm2 [1.77 TB]
  Total: 8 [8.94 TB] / in use: 3 [3.62 TB] / in no VG: 5 [5.32 TB]

Version-Release number of selected component (if applicable):

lvm2-2.02.40-6.el5    BUILT: Fri Oct 24 07:37:33 CDT 2008
lvm2-cluster-2.02.40-7.el5    BUILT: Wed Nov 26 07:19:19 CST 2008
device-mapper-1.02.28-2.el5    BUILT: Fri Sep 19 02:50:32 CDT 2008

How reproducible:
Comment 1 Jonathan Earl Brassow 2009-03-11 13:01:04 EDT
Removing 5.4 flag.

Stacking comes in two flavors:
1) The ability to stack LVs in the same vg, like creating a RAID10, etc
2) Creating new VGs on top of existing LVs in another VG.

#1 is a significant portion of work that has been talked about for a long time, but probably won't be seen in RHEL5.

#2 is possible in rudimentary forms.  When more exotic stacking takes place - like putting a VG on top of a mirror or snapshot - the concept starts to break down.  It is possible to run around and stomp out all the bugs associated with this in the RHEL5 timeframe, but I don't think anyone can be tasked to it in 5.4.
Comment 3 Mikulas Patocka 2010-10-31 23:39:34 EDT
Filter the snapshots in lvm.conf and it will work. Not a bug, but an incorrect configuration.
Comment 4 Alasdair Kergon 2010-11-01 07:11:25 EDT
If stacking on top of an origin+snapshot, the snapshot *must* be writeable and the PV uuid within it changed OR filters must be used to ignore one of the two devices.  It is impossible for any general rule to guess the right default without some level of manual intervention.
Comment 5 Mikulas Patocka 2010-11-01 07:32:04 EDT
Maybe we could change the error message to suggest to the user that he should edit "filter" clause in lvm.conf --- because this problem is repeated several times in our bugzilla.

Note You need to log in before you can comment on or make changes to this bug.