- ibmcl01 is the hostname of the LPAR… which is a VIOC too
- oravg is the name of volume group which resides on the SAN disks impacted by the export/reimport
Assuming that we want to migrate, on a VIOC, one or more currently SAN disks attached on a local fibre channel adapter to the same one or more SAN disks but now presented as SCSI storage media, seen — this time — through a VIOS.
Here is the logical steps to follow… when all things doesn’t work as expected (real life example)!
Get the list of the physical and logical volumes corresponding to the volume group:
# lsvg -p oravg oravg: PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION hdisk4 active 999 18 00..00..00..00..18 # # lsvg -l oravg oravg: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT loglv00 jfs2log 1 1 1 open/syncd N/A fslv00 jfs2 980 980 1 open/syncd /aspora11gdb01 #
Unmount the already mounted file systems:
# umount /aspora11gdb01
Deactivate a volume group and export the definition of a volume group from a set of physical volumes:
# varyoffvg oravg # exportvg oravg
Having verified that there is no physical volumes in the desired volume group using
lspv, remove them from the devices list with the corresponding adapter:
# rmdev -l hdisk4 -Rd # # lsslot -c slot # rmdev -l pci2 -Rd
We assume that the fibre channel adapter is now seen through a VIOS: it is not shown here how to dynamically move it from the LPAR to the VIOS and allocate the PVs to a particular VIOC, i.e.
ibmcl01 in our case.
Make the new disks available to the OS and verify that the presented LUNs are the right ones:
# cfgmgr # lscfg -l hdisk4 hdisk4 U9113.650.95A3E0C-V5-C4-T1-L6500000000 Virtual SCSI Disk Drive
Generally, we just have to import the
oravg volume group, activate it, mount the file systems on it and… enjoy. Since we encountered a problem during the import (the information between the VM and the ODM seems not synchronized accordingly), here are the steps we follow to recover the situation.
Reimport the volume group, redefine the set of PVs of the given VG in the device configuration database and activate it:
# importvg oravg /* Ooops... something goes wrong here! */ # redefinevg -d hdisk4 oravg /* One disk is sufficient to get the volume group information back. */ # varyonvg oravg
Ok, the PVs are back in the configuration but not the type of the LVs, according to:
# lsvg -l oravg oravg: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT loglv00 jfs2log 1 1 1 open/syncd N/A fslv00 jfs2 980 980 1 open/syncd /aspora11gdb01 #
Synchronize or rebuild the logical volume control block, the device configuration database and the volume group descriptor areas on the PVs:
# synclvodm -v -P oravg synclvodm: Physical volume data updated. synclvodm: Logical volume loglv01 updated. synclvodm: Logical volume fslv00 updated. # # lsvg -l oravg oravg: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT loglv00 jfs2log 1 1 1 open/syncd N/A fslv00 jfs2 980 980 1 open/syncd /aspora11gdb01 #
Create complete boot image and device (in order to keep the type of LVs persistent across reboot):
# bosboot -a bosboot: Boot image is 23145 512 byte blocks.
Mount the file systems and… enjoy :)