Tag Archives: Export

Aix: Export and Import a Volume Group After System Crash

  1. ibmcl01 is the hostname of the LPAR… which is a VIOC too
  2. 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 :)