I have an older redhat (5) server that needs to have 9 array filesystems moved to a new array. I'm seeking some assistance on the best way of doing this and how the process works.

The data is being copied directly as an array level copy. I have been given the 9 LUNids (WWN) from the existing server and I see them in the output of multipath -ll. I also have the LUNids on the new storage that correspond to the old. I am unsure how to migrate to the new storage. I don't fully understand the role of LVM commands like pvscan. I think the procedure is going to be to quiesce the array filesystems and unmount them and remove from /etc/fstab so they don't try to be mounted on boot. Then shutdown server and connect the new array LUNids, then boot. At this stage I expect to see the new LUNids from multipath -ll. Is this correct? And as I've not specified any custom device naming I will also see device names of the form mpathX for each? I know that each PV has a UUID, as does a VG and LV. Is that the key information that allows LVM to reconstruct each PV and consequently the volume groups and logical volumes such that it all contains the same data? That is, the PV of /dev/mapper/mpath24 from one of the new LUNid disks will be the same data because its been identified by the UUID that is on that disk?

Will this just work? After the reboot and multipath has discovered and enumerated the paths and devices (and updated /etc/multipath/bindings) will LVM simply start, automatically interrogate the disks and essentially, Just Work? So I can go ahead and mount the filesystems just as before?

If not what steps do I need to take? Do I need to run pv/vg/lv scan? It would be helpful to know what happens when multipath starts up, and what happens when LVM starts.

Lastly, is it possible to avoid a reboot, or is it safest to do that for orderliness of the processes? If I could do this without reboot what steps would I need to take after umounting filesystems and attaching the new LUNids? Is there are sequence of multipath and subsequent LVM commands that would do the same thing as a reboot process? and any additional steps I need in either case?

Thank you.



To clarify, do you intend to make a mirror with lvm and then separate them? Or is the data already replicating between arrays?

Whether the data is being replicated from array to array. The process is simple. When they are synchronized. The IO is stopped and export VG. Remove visibility to the host of current disks. Stop the replica. Split the replica. This option allows you to go back if the process does not finish correctly.

Present new disks to host. This will have a new UUID. The UUID of a LUN / volume depends on the array it is in. Import the VG from the new cab.

You finished.

Of course, multipath must be configured correctly for the new disks on the host in advance.

In any case, before doing this with production data. TEST TEST TEST the entire method with little test data from source to destination.

If you want do all work with LVM?

It is a broad and perhaps not very specific question.

To summarize. It is an ambitious task if you have no prior knowledge of LVM.

The steps would be: 1.- present the new cabin to the host. 1.a the manufacturer of the array(HP, DELL, IBM, ...) will have specific configurations of that array model for multipath.conf. Search and apply

1.b The new disks are then presented to the host.

mpathX is one of the options. Probably not the best.

1.c In multipath.conf you can define the naming of the disks.

  1. scan the new discs.

3.- Format the disks

3.a Confirm if the manufacturer needs special alignment. It usually varies if it is pv of the whole disk or a partition.

4.- Create the physical volumes

5.- From here there are several options:

5.a Add the disks to the VG and create mirrors of each of the volumes in each array.

5.a1 stop service.

5.a2 Separate the mirrors of each array --split-mirrors
5.a3 export old disks

Upon completion, you will have 1 full copy in each array.

Start service.

Doing this with production data without prior knowledge of LVM can be very dangerous.

Test You can create a new small VG, a couple of volumes, add data to the filesystems. Add disk of sufficient size from the new booth. Put them together in the same VG and do the operations of the mirror and --split-mirrors to get an idea of ​​the complete operation.

Test result


The process to move the filesystem to the new array was completed. These were the steps.

The array filesystems were quiesced and then unmounted.
The filesystems were removed from /etc/fstab so they were not mounted on boot. An array level copy of the data was made to the new storage array. The LUNs were disconnected from the old array and connected to the new array. The host was rebooted. Using the ‘multipath -ll’ command the new LUNs were observed as connected and the paths to the scsi devices (/dev/sd*) were also evident ( 4 paths corresponding to a pair of dual port HBAs). Using LVM: ‘pvs’ showed the physical devices as expected. However ‘vgs’ did not show any of the volume groups.
Ran ‘vgscan’ which then showed all the volume groups and thus ‘vgs’ did as well. However mounting the filesystem failed reporting ‘no such file or directory’ for the path /dev/mapper/vg_name/lv_name. We could not see the volume group names in that path in /dev. Ran ‘vgchange -a y ’ which ‘activated’ the volume group and then the path was visible in /dev. Mounting the filesystem then worked.
Confirmed that the data was present and it was correct. Restored /etc/fstab to include the filesystems. Performed a test reboot to ensure all well. Complete.

The understanding that LVM writes a header on the start of the disk that includes a UUID helped significantly. This is the mechanism by which the disk can be identified and kept in the correct LVM objects (pv, vg, lv) when the underlying storage paths and devices change.

Finally the lack of volume group information from ‘vgs’ initially and further when the path was not shown in /dev could have been more easily diagnosed by the use of ‘vgdisplay’ instead of ‘vgs’. ‘vgdisplay’ shows the status of the volume group and would have provided useful clues at that stage.

The whole process from connecting the new LUNs to having the machine up took around 15 minutes and would have been significantly quicker had the diagnosis of the volume group status been made straight away.

In preparation we ensured that backup copies of all relevant files and data had been made and stored separately (/etc/fstab, /etc/lvm/, /etc/multipath.conf /etc/multipathd/bindings and several more. Also captured output from pvdisplay, vgdisplay, lvdisplay, multipath -ll, fdisk -l and so on. Generated some hashes of sample data in each filesystem too use as a check - but wasn’t actually used). We also ensured that access to the console was available and maintained an active session throughout the change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.