Thursday, May 14, 2015

Linux -- Migrating a LVM Disk to a new Server

You may need to migrate your applications or database a new server using storage method such as unmapping the disks from old server and mapping them to the new one.. This method saves you time as you dont need copy from server to server, saves you from network and filesystem waits and so..
But if you have configured LVM on your disk partition, then you may get into panic, thinking what will happen to the LVM partitions in the target server..
This blog post is written to show you the way.. So as long as you Linux versions are identical / or lets say compatible, and as long as you follow this action plan, you are good to go!

Lets make an example:

Here we the disks in our source system..

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   37G   15G   21G  43% /
tmpfs                         2.0G  228K  2.0G   1% /dev/shm
/dev/sda1                     239M   54M  172M  24% /boot
/dev/mapper/vgu02-lvu02        40G  5.0G   33G  14% /u02

Lets say we unmap and map the disk mounted to /u02 ..

We umount the /u02

[root@localhost ~]# umount /u02/

[root@localhost ~]# df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   37G   15G   21G  43% /
tmpfs                         2.0G  228K  2.0G   1% /dev/shm
/dev/sda1                     239M   54M  172M  24% /boot

As you see above, it is unmount..

Then we inactivate the volume group associated with it..

[root@localhost ~]# vgchange -an vgu02
  0 logical volume(s) in volume group "vgu02" now active

Next, we export the volume group..
[root@localhost ~]# vgexport vgu02
  Volume group "vgu02" successfully exported

When we use the command to see the physical volume info, we see the vgu02 is exported as follows..

root@localhost ~]# pvdisplay
  Physical volume "/dev/sdb" of volume group "vgu02" is exported
  --- Physical volume ---
  PV Name               /dev/sdb
  VG Name               vgu02 (exported)
  PV Size               30.00 GiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              7679
  Free PE               0
  Allocated PE          7679
  PV UUID               Pu5lqh-z0ls-8bbL-kUDC-ORE6-115h-ffEl1k

So at this point our disk is ready from unmapping/mapping , or say it is ready for migration..

In this example, we use Oracle Virtual Box ..It is just for the demo, you can unmap/map your devices from your storage , it does not really matter.. It is the same thing..
Okay, we have 2 Oracle VM Server, we just clone the disk from our source vm for the use of our target vm.. We use xboxmage clonehd command..

vboxmanage clonehd "sourcepath\existingdisk.vmdk" "sourcepath\newcloneddisk.vmdk" --format VMDK

We started to target machine and executed pvscan command..

[root@orcl12c ~]# pvscan
  PV /dev/sdb     is in exported VG vgu02 [30.00 GiB / 0    free]
  PV /dev/sdc1    is in exported VG vgu02 [9.99 GiB / 0    free]
  PV /dev/sda2   VG vg_orcl12c   lvm2 [29.51 GiB / 0    free]
  Total: 3 [69.50 GiB] / in use: 3 [69.50 GiB] / in no VG: 0 [0   ]

As you see above, it discovered the PV volumes in this newly migrated disk.. We see the exported Volume Groups as well..

Next , we you vgimport the import te Volume Group..

[root@orcl12c ~]# vgimport vgu02
  Volume group "vgu02" successfully imported

At this point, we are good to go.. Our volume group is ready. Only thing we need to do is activating and mounting it..

[root@orcl12c ~]# vgchange -ay vgu02
  1 logical volume(s) in volume group "vgu02" now active
[root@orcl12c ~]# mkdir /u02
[root@orcl12c ~]# mount /dev/vg
vga_arbiter  vg_orcl12c/  vgu02/

[root@orcl12c ~]# mount /dev/vgu02/lvu02 /u02/
[root@orcl12c ~]# cd /u02/
[root@orcl12c u02]# ll
total 24
drwxrwxrwx. 4 oracle root  4096 Oct 13  2014 erman
drwxrwxrwx. 2 root   root 16384 Oct 13  2014 lost+found
drwxrwxrwx. 3 root   root  4096 Oct 13  2014 test

No comments :

Post a Comment