lvm volume group on raid1: physically move raid1 array from server 1 to server 2

Server 1 running CentOS 7.
Server 2 running CentOS 7.

I want to create an lvm volume group on two ssd hard drives configured in software RAID1 on Server 1.
Then, copy data to the volume group.
Then, pull the drives from Server 1 and plug them into empty bays on Server 2.

Server 1 -
Assume the two ssd drives are properly configured in RAID1 using mdadm.
Assume the volume group is properly configured and data can be written and read to/from the mounted partition on Server 1.

Will the following work to remove the drives from Server 1 and have them recognized on Server 2?? --

Server 1 -

vgchange -an /dev/lvm_pool/vg1
vgexport /dev/lvm_pool/vg1

power off to Server 1

Pull drives and plug them into Server 2
power on and boot Server 2

Server 2 -

vgimport /dev/lvm_pool/vg1
vgchange -ay /dev/lvm_pool/vg1

mount /dev/lvm_pool/vg1 to the desired partition or directory.

Has anyone completed this successfully with data intact?
Thanks for your help and guidance.

Originally Posted by Sum1 Will the following work to remove the drives from Server 1 and have them recognized on Server 2?? -- Server 1 - vgchange -an /dev/lvm_pool/vg1 vgexport /dev/lvm_pool/vg1 power off to Server 1 Pull drives and plug them into Server 2 power on and boot Server 2 Server 2 - vgimport /dev/lvm_pool/vg1 vgchange -ay /dev/lvm_pool/vg1 mount /dev/lvm_pool/vg1 to the desired partition or directory. Has anyone completed this successfully with data intact?

I perform exactly those steps with portable drives routinely. Just make sure the VG name doesn't conflict with something that already exists on Server 2, as that tends to cause "innumerable confusion" (to steal a term from Marshall MaLuhan's book).

Thanks for the review and confirmation, RK!

I've been muttering hopeful words all week trying to figure out a way to transfer the data quickly and get it back online without having to hover over a 1.2TB rsync over the network.

I am sorry I can't tell you my experience with a vgchange, but I have done other scary LVM thingies.

My recommendation: set up one or two VMs, use a USB stick to create a RAID on two partitions on that USB, create LVM and do what you described in your post.

It gives me a heck more confidence when I know I have tried it before in a test environment. My problem is mainly that I don't do these things often enough. So a try out with the current version of mdadm and LVM just saves my nerves.

BTW the process you described is completely according to the RedHat manual, so it should work. AFAIK the RAID array will simply start to assemble when you place it in the new machine. I take it your boot sector is not on LVM, and it might or might not be outside the RAID.

jlinkels

Originally Posted by jlinkels My recommendation: set up one or two VMs, use a USB stick to create a RAID on two partitions on that USB, create LVM and do what you described in your post.

Thanks, jlink!
Yes -- I was thinking of something very similar to try. I have a spare computer at home in which I've completed a fresh CentOS 7 install on /dev/sda, then added /dev/sdb and /dev/sdc. Partitioned sdb and sdc - Created RAID1 array on them - and created logical volume on the raid array and mounted the filesystem.
I'll pull all the hard drives.
Make a new CentOS 7 install on the computer using another hard drive.
Poweroff.
Add the sdb and sdc hard drives.
Boot.
See if the fresh install recognizes the raid1 array, logical volume, and actually able to mount the filesystem.

Originally Posted by jlinkels My problem is mainly that I don't do these things often enough.

100% spot on --- and without spare hardware in the rack to test it out, any small change to a production environment feels like a horror film.

Originally Posted by jlinkels I take it your boot sector is not on LVM, and it might or might not be outside the RAID.

That's right. The server 1 /boot is a standard partition in raid 1 with xfs filesytem; not xfs on lvm.

Thanks again for the second set of eyes, it absolutely helps to check one's thinking and assumptions.