Bug 839796 - pvmove is inconsistent and gives misleading message for raid
pvmove is inconsistent and gives misleading message for raid
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.5
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Jonathan Earl Brassow
Cluster QE
:
Depends On:
Blocks: 886216
  Show dependency treegraph
 
Reported: 2012-07-12 17:02 EDT by benscott
Modified: 2013-02-21 03:11 EST (History)
11 users (show)

See Also:
Fixed In Version: lvm2-2.02.98-4.el6
Doc Type: Bug Fix
Doc Text:
'pvmove' has been disallowed from operating on RAID logical volumes due to incorrect handling of their sub-LVs. If it is necessary to move a RAID logical volume's components from one device to another, 'lvconvert --replace <old_pv> <vg>/<lv> <new_pv>' should be used.
Story Points: ---
Clone Of:
Environment:
lvs --version LVM version: 2.02.96(2)-cvs (2012-03-06) Library version: 1.02.75-cvs (2012-03-06) Driver version: 4.22.0
Last Closed: 2013-02-21 03:11:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 benscott 2012-07-12 17:59:38 EDT
Well apparently bugzilla lost my description of the bug so here goes again:


  LVM version:     2.02.96(2)-cvs (2012-03-06)
  Library version: 1.02.75-cvs (2012-03-06)
  Driver version:  4.22.0

1. Create a raid 1 mirror like this one:

  LV               VG    Attr     LSize Copy%  Devices
  lvol0            NewVg rwi-a-m- 2.00g 8.79   lvol0_rimage_0(0),lvol0_rimage_1(0)
  [lvol0_rimage_0] NewVg Iwi-aor- 2.00g        /dev/sdg(1)
  [lvol0_rimage_1] NewVg Iwi-aor- 2.00g        /dev/sdh(1)
  [lvol0_rmeta_0]  NewVg ewi-aor- 4.00m        /dev/sdg(0)
  [lvol0_rmeta_1]  NewVg ewi-aor- 4.00m        /dev/sdh(0)


2. Run pvmove with the volume name:

pvmove --name lvol0  /dev/sdh /dev/sdi
  Skipping mirror LV lvol0
  All data on source PV skipped. It contains locked, hidden or non-top level LVs only.
  No data to move for NewVg

3. Run pvmove without the volume name:

pvmove   /dev/sdh /dev/sdi
  Skipping mirror LV lvol0
  /dev/sdh: Moved: 0.2%
  /dev/sdh: Moved: 17.7%
  /dev/sdh: Moved: 35.1%
  /dev/sdh: Moved: 53.0%
  /dev/sdh: Moved: 70.4%
  /dev/sdh: Moved: 87.7%
  /dev/sdh: Moved: 99.8%
  /dev/sdh: Moved: 100.0%

The warning is wrong, the data really was moved.

  LV               VG    Attr     LSize Copy% Devices
  lvol0            NewVg rwi-a-m- 2.00g 100   lvol0_rimage_0(0),lvol0_rimage_1(0)
  [lvol0_rimage_0] NewVg iwi-aor- 2.00g       /dev/sdg(1)
  [lvol0_rimage_1] NewVg iwi-aor- 2.00g       /dev/sdi(0)
  [lvol0_rmeta_0]  NewVg ewi-aor- 4.00m       /dev/sdg(0)
  [lvol0_rmeta_1]  NewVg ewi-aor- 4.00m       /dev/sdi(512)


3. The same results will occur with a raid stripe set, except the the
warning about skipping a mirror is not printed.
Comment 3 Corey Marthaler 2012-07-12 19:29:59 EDT
The misleading message part has come up before. :)

https://bugzilla.redhat.com/show_bug.cgi?id=500899#c6
Comment 4 Alasdair Kergon 2012-07-12 19:32:13 EDT
Well, from its point of view, it didn't move lvol0 at all - it moved the lvol0_* volumes!  So the output you quote is perfectly logical!

We'll sort out what the capabilities of these commands really are now and get them fixed.
Comment 7 Alasdair Kergon 2012-07-31 09:56:19 EDT
Corey: chicken and egg:)

The purpose of the bugzilla *is* to work out what the correct behaviour of the tools should be in all interactions between pvmove and the different types of raid devices, and then to implement that.
Comment 9 Jonathan Earl Brassow 2012-12-04 18:38:55 EST
If you look at the device-mapper mapping tables for the result of the RAID LV after the move, you find it horribly disfigured.  This should not be allowed.  I am disallowing 'pvmove' of RAID LVs for now.  The feature can be requested for RHEL6.5+.

For now, users wishing to move a particular leg of a RAID LV can use:
  'lvconvert --replace old_pv vg/lv new_pv'
Comment 10 Jonathan Earl Brassow 2012-12-04 18:56:04 EST
commit 383575525916d4cafb1c8396c95a40be539d1451
Author: Jonathan Brassow <jbrassow@redhat.com>
Date:   Tue Dec 4 17:47:47 2012 -0600

    pvmove/RAID:  Disallow pvmove on RAID LVs until properly handled
    
    Attempting pvmove on RAID LVs replaces the kernel RAID target with
    a temporary pvmove target, ultimately destroying the RAID LV.  pvmove
    must be prevented on RAID LVs for now.
    
    Use 'lvconvert --replace old_pv vg/lv new_pv' if you want to move
    an image of the RAID LV.
Comment 11 Jonathan Earl Brassow 2012-12-04 18:59:12 EST
Results:

[root@bp-01 lvm2]# devices vg
  LV            Cpy%Sync Devices                      
  lv              100.00 lv_rimage_0(0),lv_rimage_1(0)
  [lv_rimage_0]          /dev/sdb1(1)                 
  [lv_rimage_1]          /dev/sdc1(1)                 
  [lv_rmeta_0]           /dev/sdb1(0)                 
  [lv_rmeta_1]           /dev/sdc1(0)                 
[root@bp-01 lvm2]# pvmove --name lv /dev/sdb1 /dev/sdd1
  Skipping raid1 LV lv
  All data on source PV skipped. It contains locked, hidden or non-top level LVs only.
  No data to move for vg
[root@bp-01 lvm2]# pvmove /dev/sdb1 /dev/sdd1
  Skipping raid1 LV lv
  Skipping RAID sub-LV lv_rimage_0
  Skipping RAID sub-LV lv_rmeta_0
  Skipping RAID sub-LV lv_rimage_1
  Skipping RAID sub-LV lv_rmeta_1
  All data on source PV skipped. It contains locked, hidden or non-top level LVs only.
  No data to move for vg
[root@bp-01 lvm2]# devices vg
  LV            Cpy%Sync Devices                      
  lv              100.00 lv_rimage_0(0),lv_rimage_1(0)
  [lv_rimage_0]          /dev/sdb1(1)                 
  [lv_rimage_1]          /dev/sdc1(1)                 
  [lv_rmeta_0]           /dev/sdb1(0)                 
  [lv_rmeta_1]           /dev/sdc1(0)
Comment 12 Nenad Peric 2012-12-05 06:31:19 EST
Adding QA ack based on last comment. (#11)
Comment 15 Corey Marthaler 2013-01-07 17:11:24 EST
Verified that pvmove is now disallowed on raid volumes.


2.6.32-348.el6.x86_64
lvm2-2.02.98-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
lvm2-libs-2.02.98-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
lvm2-cluster-2.02.98-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
udev-147-2.43.el6    BUILT: Thu Oct 11 05:59:38 CDT 2012
device-mapper-1.02.77-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
device-mapper-libs-1.02.77-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
device-mapper-event-1.02.77-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
device-mapper-event-libs-1.02.77-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012
cmirror-2.02.98-6.el6    BUILT: Thu Dec 20 07:00:04 CST 2012


[root@hayes-01 ~]# lvs -a -o +devices
  LV                        VG          Attr      LSize  Cpy%Sync Devices
  move_during_io            rwi-a-r--  2.00g    38.28 move_during_io_rimage_0(0),move_during_io_rimage_1(0)
  [move_during_io_rimage_0] Iwi-aor--  2.00g          /dev/etherd/e1.1p9(1)
  [move_during_io_rimage_1] Iwi-aor--  2.00g          /dev/etherd/e1.1p8(1)
  [move_during_io_rmeta_0]  ewi-aor--  4.00m          /dev/etherd/e1.1p9(0)
  [move_during_io_rmeta_1]  ewi-aor--  4.00m          /dev/etherd/e1.1p8(0)

[root@hayes-01 ~]# pvmove -v /dev/etherd/e1.1p9 /dev/etherd/e1.1p10
    Finding volume group "raid_sanity"
    Archiving volume group "raid_sanity" metadata (seqno 3).
    Creating logical volume pvmove0
  Skipping raid1 LV move_during_io
  Skipping RAID sub-LV move_during_io_rimage_0
  Skipping RAID sub-LV move_during_io_rmeta_0
  Skipping RAID sub-LV move_during_io_rimage_1
  Skipping RAID sub-LV move_during_io_rmeta_1
  All data on source PV skipped. It contains locked, hidden or non-top level LVs only.
  No data to move for raid_sanity
Comment 16 errata-xmlrpc 2013-02-21 03:11:36 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-0501.html

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