IBM Support

Managing multiple instances of altinst_rootvg and applying fixes to them

Technote (FAQ)


Question

What is the recommended way of managing multiple instances of altinst_rootvg and applying interim fixes to each of the clones?

Answer

Answer
This document describes the recommended preparation and process when managing multiple instances of altinst_rootvg. We will discuss the usage of the ‘-v’ flag for the ‘alt_rootvg_op’ command, applying interim fixes when cloning the rootvg and finally post-checks and FAQ.


Managing multiple instances of altinst_rootvg and applying fixes to them

Overview


Introduction
This guide is intended for those who are new to or would like to learn more about using multiple instances of cloned rootvgs as a convenient and efficient way of managing their systems.

In this document we will use 4 hdisks (hdisk0 through hdsik3) with hdisk0 being our rootvg and the other 3 disks being blank. We will then clone our rootvg to each of the 3 remaining hdisks by using ‘alt_disk_copy’, ‘alt_disk_copy’ + ‘update_all’ and ‘nimadm’ commands.

In between each cloning process we will be renaming our rootvgs to be able to achieve the desired results, to be easier to manage and to avoid confusion.

If you would like to know more about alternate disk cloning please visit:

http://www-01.ibm.com/support/docview.wss?uid=isg3T1011055#1

About nimadm:

http://www-01.ibm.com/support/docview.wss?uid=isg3T1012571

What will this document cover?

· Creating of multiple instances of altinst_rootvg and renaming them for convenience and easy management by:
- cloning of the rootvg using the ‘alt_disk_copy’ command

- cloning and updating the rootvg using ‘alt_’ commands

- migrating the rootvg using the ‘nimadm’ command

- renaming of volume group(s) by using the ‘alt_rootvg_op’ command

· Waking up and putting back to sleep cloned/migrated disk(s)
· Applying interim fixes to the migrated and cloned disk(s)

What this document will not cover?

· Most flags used with ‘alt_’ commands
· Alternate disk clone and nimadm pre-checks and requirements
· Any NIM related operations in conjunction with ‘alt_disk_copy’
· The phases of the nimadm process
· Most flags used with the ‘nimadm’ command
· Requirements for nimadm
· Limitations for nimadm
NOTE: The above information can be found at:

http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds4/nimadm.htm

1. As mentioned above we will start with 4 hdisks with hdisk0 being our original rootvg running AIX 6100-07-04-1215 and the other 3 hdisks being blank.

#oslevel -s

6100-07-04-1216

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 None

hdisk2 00f6b08164ae5bd9 None

hdisk3 00f6b081e6e4fa23 None

2. Our first operation will be to clone the rootvg from hdisk0 to hdisk1 using the ‘alt_disk_copy’ command as follows:

#alt_disk_copy -d hdisk1

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 altinst_rootvg

hdisk2 00f6b08164ae5bd9 None

hdisk3 00f6b081e6e4fa23 None

3. Next we will wake up hdisk1, apply an ifix to it, then put it back to sleep by using the ‘alt_rootvg_op’ command:

#alt_rootvg_op -Wd hdisk1

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 altinst_rootvg active

hdisk2 00f6b08164ae5bd9 None

hdisk3 00f6b081e6e4fa23 None

#alt_rootvg_op -Cw <ifix name>.epkg.Z -l /<ifix_dir>

NOTE: It is extremely important you put the altinst_rootvg back to sleep as you run the risk of corruption if you reboot the system without doing so.

#alt_rootvg_op -S

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 altinst_rootvg

hdisk2 00f6b08164ae5bd9 None

hdisk3 00f6b081e6e4fa23 None

4. Next we will rename the altinst_rootvg on hdisk1 to hdisk0_clone and create a second clone of our rootvg to hdisk2 and apply a Service Pack update at the same time:

NOTE: Please note that AIX does not support 2 rootvgs with the same name therefore if we are to create a second clone we must rename the first clone otherwise we will have 2 rootvgs named altinst_rootvg and this is not supported. See an example of this below :

# alt_disk_copy -b update_all -l /610images/sp/6100-07-09 -d hdisk2

Calling mkszfile to create new /image.data file.

Checking disk sizes.

Creating cloned rootvg volume group and associated logical volumes.

0505-102 alt_disk_install: mkvg has returned an error.

0516-360 /usr/sbin/mkvg: The device name is already used; choose different name.

#alt_rootvg_op -v hdisk0_clone -d hdisk1

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 None

hdisk3 00f6b081e6e4fa23 None

#alt_disk_copy -b update_all -l </service pack location> -d hdisk2

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 altinst_rootvg

hdisk3 00f6b081e6e4fa23 None

5. The next operation would be to rename hdisk2 as we will create another clone of our rootvg using by using the ‘nimadm’ command.

#alt_rootvg_op -v 610709_clone -d hdisk2

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 610709_clone

hdisk3 00f6b081e6e4fa23 None

We will be using a nim master with already predefined lpp_source and SPOT at 7100-03-05.

#nimadm -c <client name> -l <lpp_source name> -s <spot name> -d hdisk3 -Y

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 610709_clone

hdisk3 00f6b081e6e4fa23 altinst_rootvg

6. Next we will rename the altinst_rootvg on hdisk3 to 710305_mig as follows:

#alt_rootvg_op -v 710305_mig -d hdisk3

#lspv

hdisk0 00f6b08195c8578a rootvg active

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 610709_clone

hdisk3 00f6b081e6e4fa23 710305_mig

7. Next we will proceed with installing an ifix on the migrated hdisk3 (710305_mig) by using the nim master and lpp_source we used for the nimadm process on hdisk3. For this operation we must boot to hdisk3. What we will do is copy the ifix to our lpp_source and tell the nim master to install the ifix on the client as follows:

First we need to locate the full path of our lpp_source:

#lsnim -l <lpp_source name> | grep location

location = </full path to lpp_source>

example:

#lsnim -l 7100-03-05_base | grep location

location = /export/lpp_source/71_03_05

Next we will need to create emgr/ppc directories in our lpp_source's main directory:

#cd </full path to lpp_source>

#mkdir -p emgr/ppc

Next we will need to move our ifix in </full path to lpp_source>/emgr/ppc

#ls </full path to lpp_source>/emgr/ppc

<ifix name >.epkg.Z

And finally we will tell the nim master to apply the ifix on the client as follows:

#nim -o cust -a filesets=<ifix name>.epkg.Z -a lpp_source=<lpp_source name> <client name>

The way the cloning process works is that when a clone is created it is aware of all the volume groups created prior to the cloning process but would not be aware of clones/rootvgs created after that. For example:

hdisk0_clone was created before 610709_clone and 710305_mig, therefore if we are to boot into hdisk0_clone it will be aware only of our original rootvg on hdisk0 and will not be aware of the other 2 clones.

#bootlist -m normal -o hdisk1

#shutdown -Fr

#lspv

hdisk0 00f6b08195c8578a old_rootvg

hdisk1 00f6b081b4d506c3 rootvg active

hdisk2 00f6b08164ae5bd9 None

hdisk3 00f6b081e6e4fa23 None

To prevent confusion and keep things clear and simple we can boot in each of the clones and set the names for each of the rootvgs so it looks like the way it’s shown on step 7.

#alt_rootvg_op -v 610709_clone -d hdisk2

#alt_rootvg_op -v 710305_mig -d hdisk3

# lspv

hdisk0 00f6b08195c8578a old_rootvg

hdisk1 00f6b081b4d506c3 rootvg active

hdisk2 00f6b08164ae5bd9 610709_clone

hdisk3 00f6b081e6e4fa23 710305_mig

#bootlist -m normal -o hdisk2

#shutdown -Fr

#lspv

hdisk0 00f6b08195c8578a old_rootvg

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 rootvg active

hdisk3 00f6b081e6e4fa23 None

#alt_rootvg_op -v 710305_mig -d hdisk3

#lspv

hdisk0 00f6b08195c8578a old_rootvg

hdisk1 00f6b081b4d506c3 hdisk0_clone

hdisk2 00f6b08164ae5bd9 rootvg active

hdisk3 00f6b081e6e4fa23 710305_mig

Frequently asked questions.

Q: Can I wake up 2 rootvgs at the same time and perform operations on them?

A: No. Only one rootvg can be woken up at a time.

Q: Is it possible to wake up a rootvg that is at a higher oslevel than the rootvg used to initiate the wake up?

A: No. The running system's operating system must be a version greater than or equal to the operating system version of the volume group that undergoes the wake up.

Q: Is there a limitation of maximum clones supported?

A: No there is no limitation.

Q: Can I update one of the clones in the future to a new Service Pack or Technology level without having to boot in it?

A: Yes. First you would wake up the rootvg undergoing the update and run the following:

#alt_rootvg_op -W -d <hdisk#>

#alt_rootvg_op -C -b update_all -l /<path to updates>

Thank you for the time to read through this guide. I hope you found the information both useful and helpful. If you feel there are any mistakes or inconsistencies, please email me at boris.borisov@bg.ibm.com. If there are any technical questions regarding this document, please follow support procedures and open a PMR by calling 1-800-426-7378, and select the option for software support.

Document information

More support for: AIX family

Software version: 6.1, 7.1

Operating system(s): AIX

Reference #: T1024618

Modified date: 17 May 2017