Export and Import a Volume Group... When Things Goes the Wrong Way

By Julien Gabel on Wednesday 6 July 2005, 23:31 - AIX - Permalink

nordika is the hostname of the LPAR... which is a VIOC too
nordikavg 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 nordikavg
nordikavg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk2            active            269         0           00..00..00..00..00
hdisk3            active            269         0           00..00..00..00..00
hdisk4            active            269         0           00..00..00..00..00
hdisk5            active            269         115         07..00..00..54..54
hdisk6            active            269         269         54..54..53..54..54
#
# lsvg -l nordikavg       
nordikavg:
LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT
loglv01             jfs2log    1     1     1    open/syncd    N/A
fslv01              jfs2       480   480   2    open/syncd    /files/tables_oragl
fslv02              jfs2       80    80    2    open/syncd    /files/oracle
fslv03              jfs2       40    40    1    open/syncd    /files/tempo_oragl
fslv05              jfs2       40    40    1    open/syncd    /files/redologs_oragl
fslv06              jfs2       40    40    1    open/syncd    /files/system_oragl
fslv07              jfs2       280   280   2    open/syncd    /files/tmpcdinst

Unmount the already mounted file systems:

# umount /files/tables_oragl
# umount /files/oracle
# umount /files/tempo_oragl
# umount /files/redologs_oragl
# umount /files/system_oragl
# umount /files/tmpcdinst

Deactivate a volume group and export the definition of a volume group from a set of physical volumes:

# varyoffvg nordikavg
# exportvg nordikavg

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 hdisk2 -Rd
# rmdev -l hdisk3 -Rd
# rmdev -l hdisk4 -Rd
# rmdev -l hdisk5 -Rd
# rmdev -l hdisk6 -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. nordika in our case.

Make the new disks available to the OS and verify that the presented LUNs are the right ones:

# cfgmgr
# lscfg -l hdisk2
  hdisk2           U9113.550.65E3A0C-V5-C5-T1-L830000000000  Virtual SCSI Disk Drive
# lscfg -l hdisk3
  hdisk3           U9113.550.65E3A0C-V5-C5-T1-L840000000000  Virtual SCSI Disk Drive
# lscfg -l hdisk4
  hdisk4           U9113.550.65E3A0C-V5-C5-T1-L850000000000  Virtual SCSI Disk Drive
# lscfg -l hdisk5
  hdisk5           U9113.550.65E3A0C-V5-C5-T1-L860000000000  Virtual SCSI Disk Drive
# lscfg -l hdisk6
  hdisk6           U9113.550.65E3A0C-V5-C5-T1-L870000000000  Virtual SCSI Disk Drive

Generally, we just have to import the nordikavg 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 nordikavg               /* Ooops... something goes wrong here! */
# redefinevg -d hdisk2 nordikavg   /* One disk is sufficient to get the volume group information back. */
# varyonvg nordikavg

Ok, the PVs are back in the configuration but not the type of the LVs, according to:

# lsvg -l nordikavg
nordikavg:
LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT
loglv01             ???        1     1     1    open/syncd    N/A
fslv01              ???        480   480   2    open/syncd    /files/tables_oragl
fslv02              ???        80    80    2    open/syncd    /files/oracle
fslv03              ???        40    40    1    open/syncd    /files/tempo_oragl
fslv05              ???        40    40    1    open/syncd    /files/redologs_oragl
fslv06              ???        40    40    1    open/syncd    /files/system_oragl
fslv07              ???        280   280   2    open/syncd    /files/tmpcdinst

Synchronize or rebuild the logical volume control block, the device configuration database and the volume group descriptor areas on the PVs:

# synclvodm -v -P nordikavg
synclvodm: Physical volume data updated.
synclvodm: Logical volume loglv01 updated.
synclvodm: Logical volume fslv01 updated.
synclvodm: Logical volume fslv02 updated.
synclvodm: Logical volume fslv03 updated.
synclvodm: Logical volume fslv05 updated.
synclvodm: Logical volume fslv06 updated.
synclvodm: Logical volume fslv07 updated.
#
# lsvg -l nordikavg
nordikavg:
LV NAME             TYPE       LPs   PPs   PVs  LV STATE      MOUNT POINT
loglv01             jfs2log    1     1     1    open/syncd    N/A
fslv01              jfs2       480   480   2    open/syncd    /files/tables_oragl
fslv02              jfs2       80    80    2    open/syncd    /files/oracle
fslv03              jfs2       40    40    1    open/syncd    /files/tempo_oragl
fslv05              jfs2       40    40    1    open/syncd    /files/redologs_oragl
fslv06              jfs2       40    40    1    open/syncd    /files/system_oragl
fslv07              jfs2       280   280   2    open/syncd    /files/tmpcdinst

Create complete boot image and device (in order to keep the type of LVs persistent across reboot):

# bosboot -a

bosboot: Boot image is 23377 512 byte blocks.

Mount the file systems and... enjoy :)

# mount /files/tables_oragl
# mount /files/oracle
# mount /files/tempo_oragl
# mount /files/redologs_oragl
# mount /files/system_oragl
# mount /files/tmpcdinst

# cfgmgr && lspv hdisk0 00c0ce845d3c0846 rootvg active hdisk1 00c0ce745d1f562b None # lqueryvg -Atp hdisk1 [...] Logical: 00c0ce7400004c00000001385d1f56b7.1 hd5 1 00c0ce7400004c00000001385d1f56b7.2 hd6 1 00c0ce7400004c00000001385d1f56b7.3 hd8 1 00c0ce7400004c00000001385d1f56b7.4 hd4 1 00c0ce7400004c00000001385d1f56b7.5 hd2 1 00c0ce7400004c00000001385d1f56b7.6 hd9var 1 00c0ce7400004c00000001385d1f56b7.7 hd3 1 00c0ce7400004c00000001385d1f56b7.8 hd1 1 00c0ce7400004c00000001385d1f56b7.9 hd10opt 1 [...]

# importvg -y testvg hdisk1 0516-530 synclvodm: Logical volume name hd5 changed to bootlv00. 0516-530 synclvodm: Logical volume name hd6 changed to pagelv00. 0516-530 synclvodm: Logical volume name hd8 changed to loglv00. 0516-712 synclvodm: The chlv succeeded, however chfs must now be run on every filesystem which references the old log name hd8. 0516-530 synclvodm: Logical volume name hd4 changed to fslv00. 0516-530 synclvodm: Logical volume name hd2 changed to fslv01. 0516-530 synclvodm: Logical volume name hd9var changed to fslv02. 0516-530 synclvodm: Logical volume name hd3 changed to fslv03. 0516-530 synclvodm: Logical volume name hd1 changed to fslv04. 0516-530 synclvodm: Logical volume name hd10opt changed to fslv05. [...] testvg # lsvg -l testvg testvg: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT bootlv00 boot 1 1 1 closed/syncd N/A pagelv00 paging 128 128 1 closed/syncd N/A loglv00 jfs2log 1 1 1 closed/syncd N/A fslv00 jfs2 7 7 1 closed/syncd /export/um_lpp_source fslv01 jfs2 64 64 1 closed/syncd N/A fslv02 jfs2 14 14 1 closed/syncd N/A fslv03 jfs2 5 5 1 closed/syncd N/A fslv04 jfs2 1 1 1 closed/syncd N/A fslv05 jfs2 11 11 1 closed/syncd N/A fslv06 jfs2 4 4 1 closed/syncd N/A lv00 sysdump 32 32 1 closed/syncd N/A fslv07 jfs2 8 8 1 closed/syncd N/A fslv08 jfs2 32 32 1 closed/syncd N/A

Comments

1. On Sunday 23 October 2011, 23:19 by xzx

hi,
thanks for the tip.

just one thing.
here on ( # importvg colombvg ) I believe you meant
importvg nordikavg. right?

2. On Monday 24 October 2011, 10:30 by Julien Gabel

You are right, thank you for commenting. Typos corrected.

3. On Sunday 20 November 2011, 17:24 by saji6659

hi,
suppose I need to import the vg to another system, so while exporting the vg, where should I export , I mean need to export to tape drive?

4. On Monday 21 November 2011, 11:25 by Julien Gabel

The problematic volume group hasn't to be imported on another system, it was imported on the real (and targeted) system.

5. On Wednesday 8 August 2012, 18:41 by Fran

I am trying to import a VG from a PV from another system in order to mount the LVs for analysis. It is the rootvg from that system. It appears I am running into an issue with duplicate LV names.

Everything is fine until synclvodm. I get this:

# synclvodm -v -P tempvg08 hd2
synclvodm: Physical volume data updated.
0516-522 synclvodm: Unable to update logical volume hd2.

Any ideas?

6. On Thursday 9 August 2012, 13:42 by Julien Gabel

The problem is that the local ODM already know about a logical volume which has the same name. Because there is only one namespace foe the devices, there can be only one name for each logical volume.

When working on a rootvg, we generally work through a network booted (mini-)environment to be able to work on the rootvg. As pointed by Benoit Creau, you can also try to import the volume using the importvg command. As stated by the manual page:

The importvg command changes the name of a logical volume if the name already exists in the system. It prints a message and the new name to standard error, and updates the /etc/filesystems file to include the new logical volume name. If the importvg command renames any filesystem log logical volumes, you must manually update any file systems using that log device to know about the renamed device.

So, here is a little test case. Verify that the second disk (hdisk1 in this case) is the rootvg of another system:

So, it seems to be the case. Then import it, and if the logical volume names are already used locally, it will be renamed on the fly:

Here, the logical volume hd2 of the other rootvg has been renamed to fslv01. Then, depending on the problem you are trying to solve, you can mount the filesystem (without forgetting to specify the jfs2log logical volume):

# mount -o log=/dev/loglv00 /dev/fslv01 /mnt
Replaying log for /dev/fslv01.

Hope this helps.

blog'o thnet

Export and Import a Volume Group... When Things Goes the Wrong Way

Comments

Add a comment

Search this Site

Personal Information

Of Interest

Categories

Subscribe (RSS)

Subscribe (Atom)