About (Enhanced) Concurrent Capable and Big vg Format Volume Group in AIX Unix

»»About (Enhanced) Concurrent Capable and Big vg Format Volume Group in AIX Unix
In AIX Unix operating system, when you try to create a volume group (vg) or alter and change a vg, there are options or flags of Concurrent Capable (or Enhanced Concurrent Capable) and Big vg Format available. The parameters are available in mkvg (create new volume group) or chvg (change the characteristics of a volume group) commands in AIX with -c (Concurrent Capable), -C Enhanced Concurrent Capable) and -B (Big vg Format) flags, or accessible via smit or smitty system management console.

Concurrent Capable or Enhanced Concurrent Capable volume group is a volume group that you can vary online on more than one AIX instance at a time. Concurrent Capable option can only be used in configurations with HACMP (not for enhanced version), HACMP ES (Group Services needed to be configured prior to using enhanced version) or Oracle RAC (aka OPS). It has no effect on volume groups and systems not using these HACMP products. A Concurrent Capable volume group is only supported on Serial DASD and SSA disks, while Enhanced Concurrent Capable volume group is supported on all other disk types. Only Enhanced Concurrent Capable supports volume group running with a 64 bit kernel.

Big vg Format meanwhile supports volume group with up to 128 physical volumes and 512 logical volumes. If you want to create a Big vg Format volume group, it’s best that you create the volume group with the setting selected, instead of trying to edit and change to volume group to support Big Format later on, as there are a lot of conditions to take care of and fulfill:

  1. The -B flag cannot be used if there are any stale physical partitions or there are any open logical volumes in the volume group.
  2. Once the volume group is converted, it cannot be imported into AIX 4.3.1 or lower versions.
  3. The -B flag cannot be used if the volume group is varied on in concurrent mode.
  4. There must be enough free partitions available on each physical volume for the VGDA expansion for this operation to be successful.
  5. Since the VGDA resides on the edge of the disk and it requires contiguous space for expansion, the free partitions are required on the edge of the disk. If those partitions are allocated for user usage, they will be migrated to other free partitions on the same disk. The rest of the physical partitions will be renumbered to reflect the loss of the partitions for VGDA usage. This will change the mappings of the logical to physical partitions in all the PVs of this VG. If you have saved the mappings of the LVs for a potential recovery operation, you should generate the maps again after the completion of the conversion operation. Also, if the backup of the VG is taken with the map option and you plan to restore using those maps, the restore operation may fail since the partition number may no longer exist (due to reduction). It is recommended that backup is taken before the conversion, and right after the conversion if the map option is utilized. Since the VGDA space has been increased substantially, every VGDA update operation (creating an LV, changing an LV, adding a PV, and so forth) may have a considerably longer duration.
  6. A big VG only supports Enhanced Concurrent Capable.

By |2016-12-09T08:40:29+00:00December 9th, 2016|Categories: Operating Systems|Tags: |0 Comments

About the Author:

LK is a technology writer for Tech Journey with background of system and network administrator. He has be documenting his experiences in digital and technology world for over 15 years.Connect with LK through Tech Journey on Facebook, Twitter or Google+.