nimadm Command

Purpose

Starting with AIX® 7.3, Technology Level (TL) 3, the nimadm command also supports AIX TL or AIX Service Pack (SP) updates.

Syntax

Perform alternate disk migration

nimadm -l lpp_source -c NIMClient -s SPOT -d TargetDisks [ -a PreMigrationScript ] [ -b installp_bundle] [ -z PostMigrationScript] [ -e exclude_files] [ -i image_data ] [ -j VGname ] [ -m NFSMountOptions ] [ -o bosinst_data] [-P Phase] [ -j VGname ] [-Y ] [ -U ] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ] [{ -B | -r }] 

Cleanup alternate disk migration on client

nimadm -C -c NIMClient -s SPOT [ -F ] [ -D ] [ -E ]

Wake-up volume group

nimadm -W -c NIMClient -s SPOT -d TargetDisks [-m NFSMountOptions ] [-z PostMigrationScript ] [ -F ] [ -D ] [ -E ]

Put-to-sleep volume group

nimadm -S -c NIMClient -s SPOT [ -F ] [ -D ] [ -E ]

Synchronize alternate disk migration software

nimadm -M -s SPOT -l lpp_source [ -d device ] [ -P ] [ -F ]

mksysb to client migration

nimadm -T NIMmksysb -c NIMClient -s SPOT -l lpp_source -d TargetDisks -j VGname -Y [ -U ] [ -a PreMigrationScript ] [ -b installpBundle ] [ -z PostMigrationScript ] [ -i ImageData ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ] [ -B | -r ]

mksysb to mksysb migration

nimadm -T NIMmksysb -O mksysbfile -s SPOT -l lpp_source -j VGname -Y [ -U ] [ -N NIMmksysb ] [ -a PreMigrationScript ] [ -b installp_bundle ] [ -z PostMigrationScript ] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ]

Client to mksysb migration

nimadm -c nim_client -O mksysbfile -s SPOT -l lpp_source -j VGname -Y [ -U ] [ -N NIMmksysb ] [ -a PreMigrationScript ] [ -b installp_bundle ] [ -z PostMigrationScript ] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -e exclude_files] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ]

Perform multi-client alternate disk migration (parallel)

With a JSON file that contains the client data

nimadm -n -f Client_json_file -Y [ -l lpp_source ] [ -s SPOT ] [ -U ] [ -a PreMigrationScript ] [ -b installp_bundle ] [ -z PostMigrationScript ] [ -e exclude_files ] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -j VGname ] [ -F ] [ -A ] [ -D ] [ -E ] [{ -B | -r }] 

Interactive option

nimadm -n -Y [ -l lpp_source ] [ -s SPOT ] [ -U ] [ -a PreMigrationScript ] [ -b installp_bundle ] [ -z PostMigrationScript ] [ -e exclude_files ] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -j VGname ] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ] [{ -B | -r }] 

Note: To view the list of mandatory and optional attributes for parallel migration, see Mandatory and optional attributes for parallel migration.

Multi-client mksysb to Client Migration (parallel)

With a JSON file that contains the client data

nimadm -n -f Client_json_file -Y [ -T NIMmksysb ] [ -l lpp_source ] [ -s SPOT ] [ -j VGname ] [ -U ] [ -a PreMigrationScript ] [ -b installp_bundle ] [ -z PostMigrationScript ] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ] [{ -B | -r }]

Interactive option

nimadm -n -Y [ -T NIMmksysb ] [ -l lpp_source ] [ -s SPOT ] [ -j VGname ] [ -U ] [ -a PreMigrationScript ] [ -b installp_bundle ] [ -z PostMigrationScript ] [ -i image_data ] [ -m NFSMountOptions ] [ -o bosinst_data ] [ -P Phase ] [ -F ] [ -A ] [ -D ] [ -E ] [ -V ] [{ -B | -r }]

Note: To view the list of mandatory and optional attributes for parallel migration, see Mandatory and optional attributes for parallel migration.

Note: You can migrate any number of client LPARs with just one CPU processor that is dedicated to NIM master. However, to fully use the parallel migration feature, you must have enough CPU processors when dealing with multiple client LPARs. If x number of CPU processors are dedicated to NIM master, then 3 x x clients can be migrated in parallel. For example, with one CPU processor that is dedicated to NIM master, three client LPARs can be simultaneously used with a maximum of 95% CPU usage to achieve maximum efficiency during multi-client nimadm operation.

Description

The nimadm command is a utility that allows the system administrator to create a copy of rootvg to a free disk (or disks) and simultaneously migrate it to a new version or release level of AIX. The nimadm command uses NIM resources to perform this function.

This document provides information about the nimadm command. For complete coverage of alt_disk_install, NIM, migration, and other related installation issues, see Installing AIX.

nimadm local disk caching

Local disk caching allows the NIM master to avoid having to NFS write to the client, which can be useful if the nimadm operation is not performing optimally due to an NFS write bottle neck. If this function is invoked with the -j VGname flag, the nimadm command creates file systems on the specified volume group (on the NIM master). Also, the nimadm command uses streams to cache all the data from the client to these file systems.

Following are the advantages and disadvantages of the nimadm local disk caching function:

Advantages

1. Improved performance for nimadm operations that are on relatively slow networks.
2. Improved performance for nimadm operations that are bottleneck in the NFS writes (NFS writes are expensive).
3. Decreased CPU usage on the client.
4. Client file systems are not exported.

Disadvantages

1. Cache file systems take up space on the NIM master (you must have enough space to host the client's rootvg file systems and migration space for each client)
2. Increased CPU usage on the master.
3. Increased I/O on the master (for optimal performance use a volume group (disk) that does not contain a NIM resource that is used in the operation).

How to execute disk caching

1. Make sure that you are at the latest level of bos.alt_disk_install.rte on the NIM master.
2. Add the -j VGName flag to any nimadm operations. For example, nimadm -j rootvg or nimadm -j cachevg.

You can exclude specific file systems (which are not involved in the migration) from being cached over the network (they are still copied locally to altinst_rootvg on the client). To specify a list of file systems to be excluded from network caching, you must create a file in the location of the SPOT resource that is used for the migration. To get the exact location of the SPOT path, enter the following command:

# lsnim -a location SpotName

The name of the file must be in the following format:

Nim_Client.nimadm_cache.excl

Note: This file applies to the NIM client specified in Nim_Client. The full path must be in the following format:

Spot_Location/Nim_Client.nimadm_cache.excl

For example, /nim_resources/520spot/usr/myclient.nimadm_cache.excl.

To exclude a file system from caching, enter one file system (to be excluded) per line in this file. To exclude a file system, you must ensure the following points:

1. Do not exclude any file systems that are involved in the migration process. In other words, these file systems contain software files that are migrated. Excluding such files can lead to unpredictable results.
2. Do not (cannot) exclude the following AIX file systems: /, /usr, /var, /opt, /home, and /tmp.

Following four phases are changed by the nimadm command with disk caching (all other phases remain the same):

• Phase 2 - The NIM master creates a local cache file system in the specified target volume group (on the NIM master).
• Phase 3 - The NIM master populates the cache file systems with the client's data.
• Phase 9 - The NIM master writes all migrated data to the client's alternate rootvg.
• Phase 10 - The NIM master cleans up and removes the local cache file systems.

nimadm requirements

Following are the nimadm requirements:

1. The NIM master must have the same level of bos.alt_disk_install.rte installed in its rootvg and the SPOT that is used to perform the migration. (Note: it is not necessary to install the alt_disk_install utilities on the client).
2. The selected lpp_source NIM resource, and selected SPOT NIM resource must match the AIX level to which you are migrating.
3. The NIM master must be at the same or higher AIX level than the level to which it is migrated.
4. The client (the system to be migrated) must be at AIX 4.3.3 or higher.
5. The client must have a disk (or disks) large enough to clone the rootvg and an extra 500 Megs (approximately) of free space for the migration. The total amount of required space depends on original system configuration and nimadm customization.
6. The target client must be a registered with the master as a stand-alone NIM client. For more information, see the niminit command. The NIM master must be able to execute remote commands on the client by using the rshd protocol.
7. The NIM master must be able to execute remote commands on the client by using the rshd protocol.
8. The NIM master and client must both have a minimum of 128 megabytes of RAM.
9. A reliable network, which can facilitate large amounts of NFS traffic, must exist between the NIM master and the client. The NIM master and client must be able to perform NFS mounts and read/write operations.
10. The client's hardware and software must support the AIX level that is being migrated to and meet all other conventional migration requirements.
11. All application and database servers, such as DB2 and LDAP, must be stopped before you run the nimadm command to clone the rootvg of a client system. Otherwise, the application servers and the database servers do not start normally after the nimadm command operations are complete.

Note: If you cannot meet requirements 1-10, you must perform a conventional migration. If you cannot meet requirement 11, then migration is not possible.

Attention: Before performing a nimadm migration, you must agree to all software license agreements for software to be installed. You can agree to all software license agreements for software to be installed by specifying the -Y flag as an argument to the nimadm command or setting the ADM_ACCEPT_LICENSES environment variable to yes.

nimadm limitations

The following limitations apply to the nimadm command:

1. If the trusted computing base (TCB) is turned on in the client's rootvg, you must disable it (permanently), use the disk caching option (-j), or perform a conventional migration. This limitation exists because TCB must access the file metadata, which is not accessible through Network File System (NFS).
2. All NIM resources that are used by the nimadm command must be local to the NIM master.
3. Although there is almost no interference with the client's active rootvg volume group during the migration, the client might experience minor reduction in performance due to increased disk I/O, biod activity, and CPU usage associated with cloning the alt_disk_install command.
4. You might need to tune the NFS to optimize the nimadm performance.
5. The reserved directory names on the NIM client for nimadm are /ALT_MIG_SPOT, /ALT_MIG_EXCL, /ALT_MIG_IMAGES, and /ALT_MIG_IMD. The nimadm command fails if these names are used.

NIM resources used by nimadm:

SPOT resource (-s flag)

The NIM spot resource is required for all nimadm operations (migration, cleanup, wake-up, sleep). All nimadm and alt_disk_install utilities that are used by the client are installed in this resource. It is not necessary to install nimadm software on the client. The NIM cust operation must be used to install the following file sets into the spot:

• Required - bos.alt_disk_install.rte (must match the NIM master's level).
• Optional message catalog - bos.msg.$LANG.alt_disk_install.rte

lpp_source resource (-l flag)

This NIM resource is the source of installation images that are used to migrate the system. It is required for nimadm migration operations. The lpp_source must contain all system images for the level to which the system is migrated (check the lpp_source images attribute in lsnim -l lpp_source output). It must also contain any optional installp images that need to be migrated.

pre-migration

This script resource that is run on the NIM master, but in the environment of the client's alt_inst file system that is mounted on the master (this operation is done by using the chroot command). This script is run before the migration begins.

post-migration

This script resource is similar to the pre-migration script, but it is executed after the migration is complete.

image_data

Specifies an image_data resource that is passed to alt_disk_install (as arguments to the -i flag). NIM allocates and mounts this resource on the client before calling alt_disk_install.

exclude_files

Specifies an exclude_files resource that is passed to alt_disk_install (as an argument to the -e flag). NIM allocates and mounts this resource on the client before calling alt_disk_install.

installp_bundle

This NIM resource specifies any additional software that the nimadm command installs after the migration is completed.

bosinst_data

This NIM resource specifies various installation settings that might be used by the nimadm command.

The nimadm migration process

The nimadm command performs migration in 12 phases. Each phase can be executed individually by using the -P flag. The nimadm phases must be run sequentially. Following are the nimadm phases:

1. The master issues an alt_disk_install command to the client that makes a copy of the rootvg volume group to the target disks (coincidentally this operation is Phase 1 of the alt_disk_install process). In this phase altinst_rootvg (alternate rootvg) is created. If a target mksysb is specified, the mksysb is used to create a rootvg volume group by using local disk caching on the NIM master.
2. The master runs remote client commands to export all the /alt_inst file systems to the master. The file systems are exported as read/write with root access to the master. If a target mksysb is specified, the cache file systems are created based on the image data from the mksysb.
3. The master NFS mounts the file systems that are exported in Phase 2. If a target mksysb is specified, the mksysb archive is restored in the cache file systems that was created in phase 2.
4. If the pre-migration script resource is specified, the script is executed during this time.
5. System configuration files are saved. Initial migration space is calculated and appropriate file system expansions are made. bos is restored and the device database is merged (similar to a conventional migration). The migration merge methods are executed and some miscellaneous processing takes place.
6. The file sets of the system are migrated by using the installp. Any required RPM images are installed during this phase.
7. If the post-migration script resource is specified, the script is executed during this time.
8. The bosboot command is executed to create a client boot image that is written to the client's boot logical volume (hd5).
9. The mounts that are made on the master in phase 3 are removed.
10. The client exports that are created in phase 2 are removed.
11. The alt_disk_install is called again (phase 3 of alt_disk_install) to make final adjustments and place altinst_rootvg to sleep. The bootlist is set to the target disk (unless the -B flag is used). If an output mksysb is specified, the cache is archived into a mksysb file and made into a NIM mksysb resource.
12. Cleanup is executed to end the migration. The client is rebooted, if the -r flag is specified.

Note: The nimadm command supports migrating several clients simultaneously.

Boot logical volume size

The nimadm command creates a boot logical volume with appropriate size to accommodate the new boot image. When you migrate your current AIX version to AIX 7.3, the size of the boot logical volume is 40 MB.

nimadm cleanup operation

This operation, indicated with the -C flag, is designed to clean up after a failed migration that for some reason did not perform a cleanup itself. It can also be used to clear a previous migration in order to perform a new migration.

nimadm wake-up and sleep

After a migration completes, the nimadm command can be used to "wake-up" the migrated altinst_rootvg or the original rootvg (if booted from the migrated disk). The nimadm wake-up (-W flag) performs an alt_disk_install wake-up, NFS exports the /alt_inst file systems, and mounts them on the NIM master. The nimadm sleep function (-S flag) reverses the wake-up by unmounting the NIM master mounts, unexporting the /alt_inst file systems, and executing the alt_disk_install sleep function on the client.

Encryption of the default logical volumes of the root volume group

Starting with AIX 7.3, TL 3, you can select the default logical volumes of the rootvg for encryption. To enable this feature, complete the following steps:

1. Create a bosinst_data resource and specify ENCRYPTLV=yes|no|preserve in the control flow stanza of the bosinst_data file.
   The ENCRYPTLV attribute have the following valid values:

   • ENCRYPTLV=yes: Enables the nimadm command encryption feature and reads the choice of the user from the lv_encryption stanza.
   • ENCRYPTLV=preserve: Enables the nimadm command encryption feature and retains the encryption status of the default logical volumes of the client rootvg when creating altinst_rootvg.
   • ENCRYPTLV=no: The default logical volumes of the altinst_rootvg are not encrypted.
2. Run the nimadm command, with the -o bosinst_data_resource_name argument.

Each logical volume in the lv_encryption stanza of the bosinst_data resource file can take the following values:

• yes - Encrypts the logical volume.
• no – Keeps the logical volume unencrypted.
• preserve - Maintains the previous state of the logical volume.

For more information about the lv_encryption stanza of the bosinst_data resource, see bosinst_data lv_encryption stanza topic.

Note: This feature supports encryption of only the default rootvg logical volumes.

To check the crypto status of altinst_rootvg, enter the following command:

hdcryptmgr showlv rootvg

Note: To encrypt 10 logical volumes, at least 11 Platform keystore (PKS) encryption slots must be available. One of the PKS encryption slots is kept as a buffer.

Starting with AIX 7.3, TL 3, all the information previously mentioned related to the migration operation by using the nimadm command also applies to an AIX TL or SP update. You can use the -U flag of the nimadm command to perform the AIX TL or SP updates.

Flags

Table 1. Flags

Item	Description
-a PreMigrationScript	Specifies the pre-migration NIM script resource.
-A	Adds a timestamp at the start of each phase of the nimadm operation. The timestamp is displayed in MM-DD-YYYY HH-MM-SS format.
-b installp_bundle	Specifies the installp_bundle NIM resource.
-B	Specifies not running bootlist after the nimadm migration. If set, then -r flag cannot be used.
-c ClientDisks	Specifies the NIM defined client that is the target of this nimadm operation. This flag is required for all nimadm operations.
-C	Performs nimadm cleanup.
-d TargetDisks	Specifies the client target disk that is used to create altinst_rootvg (the volume group that is migrated).
-D	Sets the nimadm command into debug mode. This function must be used only to debug nimadm related problems and is not set by default.
-e exclude_files	Specifies the exclude_files NIM resource. This resource is used by the alt_disk_install command during Phase 1.
-E	Enters the nimadm debugger if a serious migration error occurs.
-f Client_json_file	Specifies the full path of the JSON file that contains the data of all the client LPARs taking part in the migration. For more information about creating a JSON file, see Creating a JSON file with client LPAR data.
-F	Forces a client to unlock. Normally, the nimadm command locks a client to perform various operations. While the client is locked, other nimadm or NIM operations cannot be performed. This flag must be used only in the unusual condition that a client is incorrectly locked. A client is incorrectly locked if for some reason the nimadm command could not call cleanup after a failure.
-i image_data	Specifies the image_data NIM resource. This resource is used by the alt_disk_install command during Phase 1 and 11.
-j VGname	Creates file systems on the specified volume group (on the NIM master) and uses streams to cache all the data from the client to these file systems.
-l lpp_source	Specifies the lpp_source NIM resource to be used for this nimadm operation. This flag is required for migration operations.
-m NFSMountOptions	Specifies arguments that are passed to the mount command that mounts client resources on the master. This flag can be used to tune nimadm related NFS performance.
-M	Verifies that the levels of the alt_disk_install software (bos.alt_disk_install) on the NIM master, SPOT, lpp_source, and optional device are synchronized (match). If there is no match, the nimadm command installs the highest level that is found in the lpp_source or optional device.
-n	Switches nimadm command operations to parallel migration mode. To perform migration for multiple client LPARs, the -n flag is needed. Note: To perform nimadm operations, the client LPAR data must be provided either interactively or through a manually created JSON file. If the -n flag is used without the -f flag, the nimadm command provides an interactive questionnaire session. You can provide multiple client LPAR data by using this questionnaire to perform nimadm operations. A client_data.json file is created automatically under the /var/adm/ras directory during the interactive questionnaire session. If there is any existing file with the same name as the client_data.json file in the /var/adm/ras directory, the existing file is backed up as the client_data.json.prev file in the same directory before the new file gets created. You can also provide the full path of a customized JSON file by using the -f flag with the -n flag. For more information about the -f flag, see -f flag.
-N NIMmksysb	Specifies the unique new NIM mksysb resource to create. If the -N flag is specified, the -O flag must be specified.
-o bosinst_data	Specifies bosinst_data NIM resource.
-O mksysbfile	Specifies the file path name for the migrated mksysb. If the -O flag is specified, the -j flag and either the -c or -T flag must be specified.
-P Phase	The phase to execute during this invocation of the nimadm command. If there is more than one phase, the phases must be separated by spaces or commas. Valid phases are 1 through 12.
-r	Specifies that the client must reboot after nimadm migration is complete.
-s SPOT	Specifies the SPOT NIM resource to be used for this nimadm operation. This flag is required for all nimadm operations.
-S	Performs the nimadm sleep function. This function must be executed to end a nimadm wake-up.
-T NIMmksysb	Specifies an existing NIM mksysb resource to migrate. If the -T flag is specified, the -j flag and either the -O or -c flag must be specified.
-U	Performs an AIX TL or SP update by using the given LPP source and SPOT. Note: This option is supported starting with AIX 7.3, Technology Level 3.
-V	Turns on verbose output.
-W	Performs the nimadm wake-up function.
-Y	Agrees to the required software license agreements for software to be installed.
-z PostMigrationScript	Specifies the post-migration NIM script resource.

Mandatory and optional attributes for parallel migration

Exit Status

0

All the nimadm command-related operations that are completed successfully.

>0

An error occurred.

Security

Access Control

You must have root authority to run the nimadm command.

RBAC users

Attention RBAC users: This command can perform privileged operations. Only privileged users can run privileged operations. For more information about authorizations and privileges, see Privileged Command Database in Security. For a list of privileges and the authorizations that are associated with this command, see the lssecattr command or the getcmdattr subcommand.

Creating a JSON file with client LPAR data

The nimadm command supports multi-client LPAR migration in parallel. The data for all the client LPARs taking part in migration must be provided to perform the nimadm operations. When you use only the -n flag, you can provide one or more client LPAR data by completing the interactive questionnaire. When the -n flag is used with the -f flag, the complete path of the JSON file that contains the client LPAR data must be specified.

{
"client_1":"<name of the nim client lpar>",
"client_1_target_disk":"<Target disk for the client lpar>",
"client_1_res_lpp_source":"<LPP-source resource name>",
"client_1_res_spot":"<Spot resource name>",
"client_1_res_target_mksysb":"<existing NIM mksysb resource to migrate>",
"client_1_vgname":"<volume group (on the NIM master) to cache all of the data from the client to these file systems>",
"client_1_res_premig_script":"<premigration script resource name>",
"client_1_res_postmig_script":"<post migration script resource name>",
"client_1_res_image_data":"<Image data resource name>",
"client_1_res_exclude_files":"<Exclude files resource name>",
"client_1_res_install_img_bundle":"<Installp bundle resource name>",
"client_1_res_bosinst_data":"<Bosinst data resource name>",
"client_1_opt_nfs_mount":"<nfs mount options>",
"client_1_opt_skip_bootlist":"<Do you want to skip running bootlist after the nimadm migration? (Enter y for yes/n for no)>",
"client_1_opt_reboot":"<Should client be rebooted after migration? (Enter y for yes/n for no)>",
"client_1_opt_update":"<Do you want to perform a TL/SP update? (Enter y for yes/n for no)>"
}

{
"client_1":"aix1",
"client_1_target_disk":"hdisk1",
"client_1_res_lpp_source":"lpp1",
"client_1_res_spot":"spot1",
"client_1_res_target_mksysb":"mksysb_72Z",
"client_1_vgname":"nimadmVg1",
"client_1_res_premig_script":"premig1",
"client_1_res_postmig_script":"postmig1",
"client_1_res_image_data":"img1",
"client_1_res_exclude_files":"excl1",
"client_1_res_install_img_bundle":"instl1",
"client_1_res_bosinst_data":"bi1",
"client_1_opt_nfs_mount":"-Vcdrfs",
"client_1_opt_skip_bootlist":"y",
"client_1_opt_update":"n",

"client_2":"aix2",
"client_2_target_disk":"hdisk2",
"client_2_res_lpp_source":"lpp2",
"client_2_res_spot":"spot2",
"client_2_res_target_mksysb":"mksysb_72X",
"client_2_vgname":"nimadmVg2",
"client_2_res_premig_script":"premig2",
"client_2_res_postmig_script":"postmig2",
"client_2_res_image_data":"img2",
"client_2_res_exclude_files":"excl2",
"client_2_res_install_img_bundle":"instl2",
"client_2_res_bosinst_data":"bi2",
"client_2_opt_nfs_mount":"-vcdrfs",
"client_2_opt_skip_bootlist":"n",
"client_2_opt_reboot":"n",
"client_2_opt_update":"y"
}

Examples

1. To run nimadm migration to target NIM client aix1 by using NIM SPOT resource spot1, NIM lpp_source resource lpp1, and target disks hdisk1 & hdisk2, enter the following command:

   nimadm -c aix1 -s spot1 -l lpp1 -d "hdisk1 hdisk2" -Y

   The -Y flag agrees to all required software license agreements for software to be installed.

2. To run the same operation as in the example earlier to hdisk2, and also run pre-migration script nimscript1 and post-migration script nimscript2, enter the following command:

   nimadm -c aix1 -s spot1 -a nimscrip1 -z nimscript2 -l lpp1 -d hdisk1 -Y

3. To run nimadm cleanup on client aix1 by using NIM SPOT resource spot1, enter the following command:

   nimadm -C -c aix1 -s spot1

4. To create a migrated new mksysb resource of a client with the file name nim1, enter the following command:

   nimadm -c aix1 -s spot1 -l lpp1 -O /export/mksysb/mksysb1 -j vg00 -Y -N nim1

5. To create a new migrated mksysb resource with the file name nim3 from an existing NIM mksysb resource, enter the following command:

   nimadm -s spot1 -l lpp1 -j vg00 -Y -T nim2 -O /export/mksysb/m2 -N nim3

6. To migrate an existing NIM resource and put it on a client, enter the following command:

   nimadm -c aix1 -s spot1 -l lpp1 -d hdisk1 -j vg00 -T nim2 -Y

   Note: No changes are made to the nim2 NIM mksysb resource.
7. To show timestamps for nimadm migration to target NIM client flan003 by using NIM SPOT resource spot1, NIM lpp_source resource lpp1, and target disk hdisk1, enter the following command:

   nimadm -j nimadm -c flan003  -s  spot1 -l lpp1  -d hdisk1 -Y -A

   An output that is similar to the following example is displayed:

   Initializing the NIM master.
   
   Starting Alternate Disk Migration.
   +-----------------------------------------------------------------------------+
   01-12-2023 01:21:29 Executing nimadm phase 1.
   +-----------------------------------------------------------------------------+
   Cloning altinst_rootvg on client, Phase 1.
   
   for backup and restore into the alternate file system...
   Phase 1 complete.
   +-----------------------------------------------------------------------------+
   01-12-2023 01:22:32 Executing nimadm phase 2.
   +-----------------------------------------------------------------------------+
   Creating nimadm cache file systems on volume group nimadm.

8. To run the nimadm operation by using the interactive mode for two NIM clients, aix1 and aix2, with target disks hdisk1 and hdisk2, respectively, NIM SPOT resource as spot1, NIM lpp_source resource as lpp1, and with other different resources, enter the following command:

   nimadm -n -Y

   An interactive session similar to the following starts to get information required for nimadm operations:

   Client #1
   ##############Enter client name -
   aix1
   Enter target disk -
   hdisk1
   No lpp_source is provided in the command line.
   Enter lpp_source name -
   lpp1
   No spot is provided in the command line.
   Enter spot name -
   spot1
   No "-T" argument specified in the command line.
        Type "mksysb" to perform mksysb to client migration.
        Otherwise, type "." to go ahead with normal migration
   mksysb
   Enter target mksysb resource -
   mksysb_72Z
   Enter vgname -
   nimadmVg1
   Enter pre-migration script resource or "." to skip -
   premig1
   Enter post-migration script resource or "." to skip -
   postmig1
   Enter image.data resource or "." to skip -
   img1
   Enter exclude files resource or "." to skip -
   excl1
   Enter install image bundle resource or "." to skip -
   instl1
   Enter bosinst_data resource or "." to skip -
   bi1
   Enter nfs mount options or "." to skip -
   -Vcdrfs
   Do you want to skip running the bootlist after nimadm migration? (yes/no)
   Note - Entering "yes" will set "-B" flag in the nimadm command -
   yes
   Would you like to update using provided lpp_source and spot? (yes/no)
   Note - Entering "yes" will set "-U" flag in the nimadm command -
   no
   Do you want to add any more clients? Type 'y' for yes, 'n' for no
   y
   
   Client #2
   ##############Enter client name -
   aix2
   Enter target disk -
   hdisk2
   No lpp_source is provided in the command line.
   Enter lpp_source name -
   lpp2
   No spot is provided in the command line.
   Enter spot name -
   spot2
   No "-T" argument specified in the command line.
        Type "mksysb" to perform mksysb to client migration.
        Otherwise, type "." to go ahead with normal migration
   mksysb
   Enter target mksysb resource -
   mksysb_72X
   Enter vgname -
   nimadmVg2
   Enter pre-migration script resource or "." to skip -
   premig2
   Enter post-migration script resource or "." to skip -
   postmig2
   Enter image.data resource or "." to skip -
   img2
   Enter exclude files resource or "." to skip -
   excl2
   Enter install image bundle resource or "." to skip -
   instl2
   Enter bosinst_data resource or "." to skip -
   bi2

   
   Enter nfs mount options or "." to skip -
   -vcdrfs
   Do you want to skip running the bootlist after nimadm migration? (yes/no)
   Note - Entering "yes" will set "-B" flag in the nimadm command -
   no
   Should the client reboot automatically after nimadm migration is complete? (yes/no)
   Note - Entering "yes" will set "-r" flag in the nimadm command -
   no
   Would you like to update using provided lpp_source and spot? (yes/no)
   Note - Entering "yes" will set "-U" flag in the nimadm command -
   yes
   Do you want to add any more clients? Type 'y' for yes, 'n' for no
   n

   
   Starting:/usr/sbin/nimadm -c aix2 -d hdisk2 -l lpp2 -s  spot2 -T mksysb_72X -j nimadmVg2 -i img2 -o bi2 -e excl2 -b instl2 -a premig2 -z postmig2 -m -vcdrfs -Y -A 2>/var/adm/ras/nimadm_parallel/aix2_error.log
   Starting:/usr/sbin/nimadm -c aix1 -d hdisk1 -l lpp1 -s  spot1 -T mksysb_72Z -j nimadmVg1 -i img1 -o bi1 -e excl1 -b instl1 -a premig1 -z postmig1 -m -Vcdrfs -B -Y -U -A 2>/var/adm/ras/nimadm_parallel/aix1_error.log
   02-21-2024 09:40:38 : Started nimadm for aix2
   02-21-2024 09:40:38 : Started nimadm for aix1
   ...
   
   # cat /var/adm/ras/client_data.json
   {
   "client_1":"aix1",
   "client_1_target_disk":"hdisk1",
   "client_1_res_lpp_source":"lpp1",
   "client_1_res_spot":"spot1",
   "client_1_res_target_mksysb":"mksysb_72Z",
   "client_1_vgname":"nimadmVg1",
   "client_1_res_premig_script":"premig1",
   "client_1_res_postmig_script":"postmig1",
   "client_1_res_image_data":"img1",
   "client_1_res_exclude_files":"excl1",
   "client_1_res_install_img_bundle":"instl1",
   "client_1_res_bosinst_data":"bi1",
   "client_1_opt_nfs_mount":"-Vcdrfs",
   "client_1_opt_skip_bootlist":"y",
   "client_1_opt_update":"n",
   
   "client_2":"aix2",
   "client_2_target_disk":"hdisk2",
   "client_2_res_lpp_source":"lpp2",
   "client_2_res_spot":"spot2",
   "client_2_res_target_mksysb":"mksysb_72X",
   "client_2_vgname":"nimadmVg2",
   "client_2_res_premig_script":"premig2",
   "client_2_res_postmig_script":"postmig2",
   "client_2_res_image_data":"img2",
   "client_2_res_exclude_files":"excl2",
   "client_2_res_install_img_bundle":"instl2",
   "client_2_res_bosinst_data":"bi2",
   "client_2_opt_nfs_mount":"-vcdrfs",
   "client_2_opt_skip_bootlist":"n",
   "client_2_opt_reboot":"n",
   "client_2_opt_update":"y"
   }
   

   
9. To run the nimadm operation by using a JSON file that contains client LPAR data, enter the following command:

   nimadm -n –f /home/dev/client_data.json -l lpp1 –s spot1 -Y

   In this example, the JSON file client_data.json is placed under the /home/dev directory. All the client LPARs mentioned in the JSON file use NIM SPOT resource spot1 and NIM lpp_source resource lpp1.

   
10. To perform an AIX TL or SP update by using the nimadm command to target the NIM client aix1 by using NIM SPOT resource spot1, NIM lpp_source resource lpp1, and target disks hdisk1 and hdisk2, enter the following command:

    nimadm -c aix1 -s spot1 -l lpp1 -d "hdisk1 hdisk2" -Y -U

    Note: The -Y flag agrees to all the required software license agreements for the software to be installed.
11. 
    To run nimadm migration to target NIM client aix1 by using NIM SPOT resource spot1, NIM lpp_source resource lpp_source1, target disk hdisk2, and to use bosinst_data resource file nim_bosinst_resource to enable the feature that allows to select the logical volumes of the default rootvg for encryption, enter the following command:

    nimadm -c aix1 -s spot1 -l lpp1 -o nim_bosinst_resource -d "hdisk2" -Y

    

Files