Imp Plan for : Extending a filesystem on an Lpar that uses vio provided disks

High level steps –

- OSA will receive a Change Request asking for more space be added to a specific filesystem on an lpar.

- OSA will check lpar for the current availability of disk space for the extension within the current volume group (vg) home of the filesystem requested in the Change Request.

- If more disk space is needed – OSA will open a task of off the CM for the SAN Team (ais distributed storage) to allocate more disk space

-The step to add the space will be one of two options / procedures depending on if the filesystem is in a scalable vg

a. if the vg is scalable the SAN team will expand the disks on the vio servers > lpar, then the OSA will expand the vg > lv > fs on the lpar

b. if the vg is not scalable the SAN team will provide a new disk from the vio servers > lpar that is the size of the orig vg disk currently on the lpar + the newly needed space. The OSA will then add the new disk to the lpar > vg / migratepv the data from current to new disk / extend the lv > fs / remove original disk from lpar > vio servers and give it back to the SAN team.

1. Determining the type of vg > extension option

a. lslv –L <lvname> (this will give you the vgname for the lv/fs you are working with – you will need to put the vgname into the work log of the task for the ais distributed storage team)

b. lsvg –L <vgname> - if the MAX pvs = 1024 or higher, the vg should be scalable. see step 3 below and put that info into the work log of the task for the ais distributed storage team

- if the MAX pvs = anything below 1024 then the vg is not scalable (the current standard is to make all vgs scalable during build). See step 4 below and put that this extension will need a new disk for migration in the work log of the ais distributed storage task)

2. The following is the procedure/details needed for opening a task to request more disk space from the SAN team (ais distributed storage) :

* Note – any request of 10G or more will need to be approved by Ahold, this takes no action by the OSA, just fyi as it will take a day or so longer for the SAN task to be completed.

a. Putting in Task requesting storage :

Category – distributed hardware - Type – disk array - Detail – drive - Brief description – add hardware - Business Impact – use same as parent CM - Exposure / risk – use same as parent CM - Post Significant Events – NO - Is disaster recovery impacted – use same as parent CM - Assigned Group – ais distributed storage - Status – approval requested - Description – use “description from parent” button - Put the vgname for the lv / fs in the work log - Put if the vg is scalable or needs to have a new disk for - migration in the work log - Requested/planned dates – go with default (unless the SAN tasks dates after the dates on the parent CM in that case the parent CM may need it’s dates extended via an email request to the CM requestor) - Choose the “Companies & Domains Affected” – ais, giant-c, s&s (look at the parent CM and choose the same. - Choose use same info as requestor on the top of the task (the owner of the task to the SAN team should be the same as the CM assigned to OSA)

- Put the parent CM in “work in progress status and update the worklog with the following “opened task for dist storage requesting the disk space, osa will configure disk space once avail”

3) The following is the procedure for extending the existing disk / volume group size > volume > filesystem on an Lpar / volume group that is scalable

a. OSA will either engage the SAN team ( ais distributed storage) via task with need for more disk space (see step 1 above)

b. SAN Team will expand the existing disks assigned to volume group within which the filesystem exists.

c. OSA will perform the following steps… - chvg –g <volume group name> (this will make the vg re-read it’s disk and add the

space - extendlv <lv name> <# of pps needed to meet the requested fs extension> - chfs –a size=+<# of MB or GB, whichever is easier requested> <filesystem name>

4) The following is the procedure for Adding a new Disk to Lpar via VIO > Migrating data between original disk and new larger disk on

Lpar > extending volume and fs on new disk > Removing original Disk from Lpar and VIO

* The following procedures and commands assume the Sysadmin is aware of the naming conventions differences from SAN > VIO > LPAR. And also that the OSA is aware of the vio shell and system shell and their uses for the below steps on the vio servers. (the $ prompt is the vio shell, you login via this shell with padmin userid, use oem_setup_env to get to the system shell that uses the # prompt.) for more info on vio servers check out this link http://www.redbooks.ibm.com/abstracts/redp4061.html

a. OSA will either engage the SAN team ( ais distributed storage) via task with need for more disk space (see step 1 above)

b. Once the disk have been carved out on the SAN and made avail to the server frame/vio server proceed with the following:

c. on both vio1 and vio2 – login to the vio shell via padmin userid at the $ prompt type $ oem_setup_env

d. at the system prompt type # lspv (check the hdisk count and assignments) (you can do this by creating a “before” output of lspv – lpsv > bef)

e. on both vio1 and vio2 – ctrl D to get back in the vio shell : $ cfgdev (check # lspv again the “new” disk(s) should now be listed – lspv > aft then diff bef aft)

f. at the system # prompt edit the # vi share_disk.sh script on vio server.

- s = starting point of the “new” disk names within the vio…i.e. “10” for hdisk10. - e = ending point of the “new” disk names within the vio…i.e. “13” for hdisk13. - Vhost = Lpar # i.e. 4 (check the profile to make sure, but the lpar # is included in the hostname of the lpar at AIS – see note below for more details)g. on both vio1 and vio2 - # ./share_disk.sh (this will assign the new disk to the

Lpar)

h. on lpar - # cfgmgr (to pull the new disk into the ODM database, this will assign the normal “hdisk#” to the “new” disk)

i. Match up “new” disk assigned to the “old” disk by size, the “new” disk will be carved out to match the “old” disk and or will be the size of the “old” disk + any requested space (rootvg disk default size in AIS env is 10G, corevg default size in the AIS en is 12G, appvg and dbvg will vary depending on app and db uses)

j. on lpar - # extendvg <vgname> <hdisk#> (add the new disk to the existing vg it is intended for)

k. on lpar – # migratepv <source/old disk> <“target/new disk> & (run as nohup because this may take a while depending on disk size being migrated, you can check the status by running a ps –ef | grep migratepv on the lpar)

l. on lpar - #reducevg <source disk>

m. on lpar - # rmdev –dl <source disk>

n. on both vio1 and vio2 - $ rmvdev –vdev <source> ( specific name when it was assigned to lpar, the pvid is the same on the vio and lpar double check)

2.  on both vio1 and vio2- $ rmdev –dev <source> (hdisk # on vio – again pvid should be the same but the hdisk# will probably differ)

3. on both vio1 and vio2 – (send the pcmpath output from the removed disk back to dist storage team)

(i.e. device 6 will = hdisk6, in this example hdisk6 (on the vio) is your source disk)

# pcmpath query device 6

DEV#:   7  DEVICE NAME: hdisk7  TYPE: 2145  ALGORITHM:  Load BalanceSERIAL: 60050768018500AEA0000000000002A3==========================================================================Path#      Adapter/Path Name          State     Mode     Select     Errors    0           fscsi0/path0           OPEN   NORMAL   69765044          3    1*          fscsi0/path1           OPEN   NORMAL         20          1    2           fscsi1/path2           OPEN   NORMAL   68721664          3    3*          fscsi1/path3           OPEN   NORMAL         19          1