But trust me, it may not be as daunting a task as you may think. Bear with me for a bit as I outline the steps needed to perform this task, successfully and without complications.
The previous article, Add LUNs to a Linux Host Without Reboot suggested the use of a well working script "rescan-scsi-bus.sh" via installation of the sg3_utils RPM. This task will do the same thing. So if this package is not installed, the script will probably be missing from your system as well. It would be a good idea to install it (yum -y install sg3_utils).
The first task on the list is to expand the LUN on the storage level. If you have an EMC storage, get to Unisphere and expand the LUN or the OnCommand System Manager for NetApp. On other storage systems, use the tools native to the storage to expand. Once that is done use rescan-scsi-bus.sh to rescan the LUNs.
For me (and some of you), "rescan-scsi-bus.sh -l" may already work. If not, use "rescan-scsi-bus.sh --forcerescan" to detect the new LUN sizes.
NOTE: The examples below will use the multipath device /dev/mpath/mpath165; and, /dev/sdat, /dev/sdh, /dev/sdap and /dev/sdd as its underlying devices. Its size is 190GB and we will add 100GB to it.
Next, check the devices relevant to the LUN. In this case -- mpath165. Change this with the multipath alias of your LUNs. Execute:
[root@vhost ~#] multipath -l mpath165 mpath165 (36006016098402e007cb4e6580ef1e311) dm-17 DGC,VRAID [size=190G][features=1 queue_if_no_path][hwhandler=1 alua][rw] \_ round-robin 0 [prio=0][enabled] \_ 1:0:1:3 sdat 66:208 [active][undef] \_ 0:0:1:3 sdh 8:112 [active][undef] \_ round-robin 0 [prio=0][active] \_ 1:0:0:3 sdap 66:144 [active][undef] \_ 0:0:0:3 sdd 8:48 [active][undef]
The above output means there are four (4) paths composing the multipath device mpath165. They are /dev/sdat, /dev/sdh, /dev/sdap and /dev/sdd. The outputs on your system may vary.
Then, let the system detect the new size of the LUNs.
[root@vhost ~#] blockdev --rereadpt /dev/sdat [root@vhost ~#] blockdev --rereadpt /dev/sdh [root@vhost ~#] blockdev --rereadpt /dev/sdap [root@vhost ~#] blockdev --rereadpt /dev/sdd [root@vhost ~#] blockdev --getsz /dev/sdat 608174080 [root@vhost ~#] blockdev --getsz /dev/sdh 608174080 [root@vhost ~#] blockdev --getsz /dev/sdap 608174080 [root@vhost ~#] blockdev --getsz /dev/sdd 608174080
From the above commands, only getsz will provide an output. The outputs will be the same (due to the multipathing) and note them down for the commands we will execute later. If the outputs of "getsz" are not the same, something is wrong. Re-execute "blockdev --rereadpt" for that particular device.
Provided the outputs are all the same, proceed with the instructions below.
Next, dump the current multipath configuration and write the output to files -- mpath165.bak.
[root@vhost ~#] dmsetup table mpath165 | tee mpath165.bak 0 398458880 multipath 1 queue_if_no_path 1 alua 2 2 round-robin 0 2 1 66:208 1000 8:112 1000 round-robin 0 2 1 66:144 1000 8:48 1000
Create a copy of the file "mpath165.bak" -- say "mpath165.new". Edit this file and replace the second number (398458880, which is the current size of the LUN) with the output of "blockdev --getsz" above.
(NOTE: Double check that the file mpath165.new has new values, where what used to be 398458880 should now be 608174080.)
This is the part where the LUN gets to be offline for a split second. It is imperative to stick these commands together. Or else..
[root@vhost ~#] dmsetup suspend mpath165; \ dmsetup reload mpath165 mpath165.new ; \ dmsetup resume mpath165
What actually happens in the above command is the multipath device mpath165 got suspended. Its configuration was replaced with the configuration contained in the file mpath165.new (or a resize was made). Then, the I/O operations were resumed. This was done quickly enough as if nothing happened.
Notify the kernel of a change of partition tables. Try partprobe first.
[root@vhost ~#] partprobe /dev/mpath/mpath165 -- or -- [root@vhost ~#] kpartx -a /dev/mpath/mpath165 [root@vhost ~#] kpartx -l /dev/mpath/mpath165
Now its time for LVM to take care of the rest of the resizing. When done right, this procedure can save you from unnecessary downtime due to multipath LUN resizing. Having known this procedure, resizing multipath LUNs will be just a routine for you.
