Tuesday , 23 April 2019
Breaking News

Migrating Physical Volumes in a LVM2 Volume Group

Scenario: mpath0p1 – 1 TB SATA disk

               mpath1    – 3 TB SAN LUN

pvcreate the new (3TB FC) disk

    #pvcreate /dev/mapper/mpath1

Now, add this disk into the oraproddb Volume Group

       # vgextend oraproddb /dev/mapper/mpath1

we need the physical extends from the new disk to be “available physical extents” in order to perform the migration.Start migration from the /dev/mapper/mpath0p1 (2.0TB SATA disk) PV to the new /dev/mapper/mpath1 (3TB FC disk) PV.

    # pvmove -b /dev/mapper/mpath0p1 /dev/mapper/mpath1

For 2.0TB SATA to 3TB FC, on different filers and different shelves, this took couple of hours to complete.

Make sure to check the migration progress… Take a look in the “Copy%” column for the LV and VG that you’re on.

    # lvs -a -o+devices

When the migration is completely finished, you will know because the “Copy%” column will no longer register a value for the LV and VG that you’re working in.

Now, you can safely remove the original PV (2.0TB SATA) from the VG. pvmove has already performed all of the necessary backend changes required to ensure that all of the data is going to the new disk.

    # vgreduce oraproddb /dev/mapper/mpath0p1

    # pvremove /dev/mapper/mpath0p1

And, lastly, perform the filesystem resize as we already know how to. Without specifying a new size, of course, it instruct the filesystem to consume the entire length of the Logical Volume.

# resize2fs /dev/mapper/oraprod-data

# mount -o remount /dev/mapper/oraprod-data


Leave a Reply