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.
The misleading message part has come up before. :) https://bugzilla.redhat.com/show_bug.cgi?id=500899#c6
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.
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.
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'
commit 383575525916d4cafb1c8396c95a40be539d1451 Author: Jonathan Brassow <jbrassow> 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.
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)
Adding QA ack based on last comment. (#11)
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
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