Let’s discuss one practical aspect where we have created LVM over shared storage and will perform a LVM migration over there.
SETUP INFO:
Iscsi target server = servervm
Iscsi initiator node1 = clientvm
Iscsi initiator node1 = test4
1. Shared storage is visible on both clients are symlinked as /dev/scsid
[root@clientvm ~]# ll /dev/scsid
lrwxrwxrwx. 1 root root 3 Jun 6 03:04 /dev/scsid -> sdb
[root@clientvm ~]# fdisk -l /dev/scsid
Disk /dev/scsid: 1073 MB, 1073741824 bytes
34 heads, 61 sectors/track, 1011 cylinders
Units = cylinders of 2074 * 512 = 1061888 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
[root@test4 ~]# ll /dev/scsid
lrwxrwxrwx. 1 root root 3 May 11 20:56 /dev/scsid -> sdd
[root@test4 ~]# fdisk -l /dev/scsid
Disk /dev/scsid: 1073 MB, 1073741824 bytes
34 heads, 61 sectors/track, 1011 cylinders
Units = cylinders of 2074 * 512 = 1061888 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
2. Creating LVM partitions on one of server:
Now creating partition on one of client node and updating partition table on master and logout/login on other client showing new partition.
Note : Actual disk may vary on different nodes, as per count of previous nodes.
[root@servervm ~]# ll /dev/sdb*
brw-rw—-. 1 root disk 8, 16 Jun 5 23:22 /dev/sdb
brw-rw—-. 1 root disk 8, 17 Jun 5 23:25 /dev/sdb1
[root@servervm ~]#
[root@clientvm /]# ll /dev/scsi*
lrwxrwxrwx. 1 root root 3 Jun 6 03:13 /dev/scsid -> sdb
lrwxrwxrwx. 1 root root 4 Jun 6 03:13 /dev/scsid1 -> sdb1
[root@clientvm /]#
[root@test4 ~]# ll /dev/scsid*
lrwxrwxrwx. 1 root root 3 May 11 21:01 /dev/scsid -> sdd
lrwxrwxrwx. 1 root root 4 May 11 21:01 /dev/scsid1 -> sdd1
[root@test4 ~]#
Now bringing disk under LVM on one of node : Refer previous tutorial to bring disks under LVM control
[root@clientvm /]# mount /dev/vg1/lv1 /mnt
[root@clientvm /]#
[root@clientvm /]# cat /mnt/testing.txt
Its a test file verifying DG deportation.
[root@clientvm /]#
3 Now processing with VG migration:
a) Unmount the mount point and deactivate VG (vgchange) you want to migrate : Make sure that no users are accessing files on the active volumes in the volume group, then unmount the logical volumes.
[root@clientvm /]# umount /mnt
[root@clientvm /]#
Deactivate the volume group using vgchange with -a -n
[root@clientvm /]# vgchange -an vg1
0 logical volume(s) in volume group “vg1” now active
[root@clientvm /]#
b) Now export affected VG so that it can be migrated to another nodes (vgexport)
The vgexport command makes an inactive volume group inaccessible to the system, which allows you to detach its physical volumes.
[root@clientvm /]# vgexport vg1
Volume group “vg1” successfully exported
[root@clientvm /]#
[root@clientvm /]# vgscan | grep -i vg1
Found exported volume group “vg1” using metadata type lvm2
[root@clientvm /]#
[root@clientvm /]# vgdisplay vg1 | grep -i “VG Status”
VG Status exported/resizable
[root@clientvm /]#
Verifying same on another node where shared storage exist
[root@test4 ~]# vgdisplay vg1 | grep -i “VG Status”
VG Status exported/resizable
[root@test4 ~]#
c). Now importing VG to new node (vgimport)
The vgimport command makes a volume group accessible to a machine again after the vgexport command has made it inactive.
[root@test4 ~]# vgimport vg1
Volume group “vg1” successfully imported
[root@test4 ~]#
[root@test4 ~]# vgdisplay vg1 | grep -i “VG Status”
VG Status resizable
Verifying status on original node where volume group was initially created
[root@clientvm /]# vgdisplay vg1 | grep -i “VG Status”
VG Status resizable
[root@clientvm /]#
d) Activating the volume group (vgchange -a -y) and mount to see if data is unimpaired
[root@test4 ~]# vgchange -ay vg1
1 logical volume(s) in volume group “vg1” now active
[root@test4 ~]#
[root@test4 ~]# mount /dev/vg1/lv1 /mnt
[root@test4 ~]#
[root@test4 ~]# cat /mnt/testing.txt
Its a test file verifying DG deportation.
[root@test4 ~]#
Your technical Mate 