Chris's AIX Blog

Just the other day, I needed to use the AIX splitvg command in order to copy some data from one system to another.

I thought I’d share the experience here.

The splitvg command can split a single mirror copy of a fully mirrored volume group into a separate “snapshot” volume group.

From the man page:

The original volume group VGname will stop using the disks that are now part of the snapshot volume group SnapVGname. Both volume groups will keep track of the writes within the volume group so that when the snapshot volume group is rejoined with the original volume group consistent data is maintained across the rejoined mirrors copies. Notes:

1To split a volume group, all logical volumes in the volume group must have the target mirror copy and the mirror must exist on a disk or set of disks. Only the target mirror copy must exist on the target disk or disks.

2The splitvg command will fail if any of the disks to be split are not active within the original volume group.

3In the unlikely event of a system crash or loss of quorum while running this command, the joinvg command must be run to rejoin the disks back to the original volume group.

4There is no concurrent or enhanced concurrent mode support for creating snapshot volume groups.

5New logical volumes and file system mount points will be created in the snapshot volume group.

6The splitvg command is not supported for the rootvg.

7The splitvg command is not supported for a volume group that has an active paging space.

8When the splitvg command targets a concurrent-capable volume group which is varied on in non-concurrent mode, the new volume group that is created will not be varied on when the splitvg command completes. The new volume group must be varied on manually.

So, looking at point 4, above, if you are using enhanced concurrent volume groups (for example with PowerHA), then you will not be able to use the splitvg command. This is disappointing as this would have been very handy in some of the large PowerHA systems I have worked with…..perhaps this will be supported in the future?

Anyway, back to my example. I had wanted to break-off one of the mirrors of a mirrored volume group and then assign the “split” volume group to another host to copy some data off.

The volume group datavg contained two disks, hdisk0 and hdisk3, as shown in the lspv output below.

The new volume group contains a new logical volume (pre-fixed with fs i.e. fsfslv00) and a file system (pre-fixed with /fs i.e. /fs/data). I can mount this file system and access the data in the file system and create and/or modify files (as shown below).

During the testing of the migration process we noticed that some of
the sys0 tunables were being reset to their default settings after the
migration had completed. This was rather odd. I’d never had this issue during
an AIX migration in the past.

We noticed the following attributes had changed.

fullcore-
Was set to true before migration. Set to false after migration.

iostat-
Was set to true before migration. Set to false after migration.

maxuproc-
Was set to 2048 before migration. Set to 128 after migration.

The maxuproc value wasof particular concern as it has an impact on the number of processes an
application (user) can start. So when one of our SAP/Oracle test systems was
unable to start because maxuproc was set to low, we were very puzzled.
After we had discovered that maxuproc was incorrect, we changed it to the
appropriate value and restarted SAP/Oracle successfully. We were then very determined to
identify the root cause of this issue. We could not see any issue with our
migration process (via nimadm) and decided to log a call with IBM.

IBM AIX support were able to assist us in determining the problem.

---------------------

After building more debug methods and performing
further debug, which

involves multiple restore attempts, we figured out
the root cause.

- During second phase of boot, when cfgsys_chrp
run, it tries to set all

customized values for sys0 device.However, in this process, if and

when an error occurs, all customized values for
sys0 will be reset to

allow the system to boot. (Instead of hang/crash).

- In the case of the customer's scenario, when
cfgsys_chrp() tries to set ncargs

to value of 30, it fails with an error.Reason being, for

AIX 6.1, minimum value for ncargs is 256. If it is
less than 256, the kernel

returns an error and then cfgsys_chrp
"resets" all customized attribute