nim_move_up Command

1. Create a system backup of the client
2. Migrate the backup's level of AIX
3. Install the backup onto an LPAR that resides on the new POWER server, which is be represented in the NIM environment as a new standalone client.

After a successful migration, the following conditions are true:

• The NIM master remains the same.
• The LPAR on the new POWER server correspond to the original NIM clients and are controlled by the NIM master.
• An HMC controls the LPAR on the new POWER servers by communicating with the NIM master through SSH.
• The original NIM clients remain unaffected and still in control of the NIM master.

The following NIM master requirements must be met before running the nim_move_up application:

• Running AIX 5L Version 5.3 with the 5300-03 Recommended Maintenance package, or later.
• Perl 5.6 or later.
• OpenSSH (from the Linux® Toolbox CD)
• At least one standalone NIM client running AIX 4.3.3 update or later in the environment
• Product media version AIX 5L Version 5.2 with the 5200-04 Recommended Maintenance package or later, or product media version AIX 5.3 or later (the equivalent LPP_Source and spot NIM resources can also be used).

In addition, the following prerequisites must be available:

• A POWER server with sufficient hardware resources to support the target clients' equivalent POWER server configuration.
• An installed and configured Virtual I/O server is, if virtual resources will be used to migrate the clients.
• An HMC controlling the POWER server, along with sufficient privileges to power-on, power-off, and create LPAR.

1. Create NIM resources. The NIM resources required to perform the migration steps are created if they do not already exist.
2. Assess premigration software. An assessment of which software is installed and which software cannot be migrated is performed on each target client. Any software missing from the LPP_Source is added from the source of the installation images (such as product media) that is provided to nim_move_up.
3. Collect client hardware and usage data. Data about each target client's hardware resources are gathered. Also, an attempt to assess the average use of those resources over a given amount of time is made.
4. Collect POWER server resource availability data and translate client resource data. The managed system that is provided is searched for available hardware resources. The data gathered in the previous phase is used to derive an equivalent LPAR configuration that uses the managed system's available resources. If a Virtual I/O server LPAR was provided to work with, the derived client LPAR is created with virtual I/O resources instead of physical I/O resources. The appropriate adapters and configuration are created on the Virtual I/O server as needed.
5. Create system backups of target clients. After NIM performs a mksysb of each target client, the corresponding mksysb NIM resources are created.
6. Migrate each system backup. Using the NIM resources designated by nim_move_up, each mksysb resource is migrated to the new level of AIX by the nimadm command. The original mksysb NIM resources are preserved and new mksysb NIM resources are created for the new migrated mksysb resources.
7. Allocate NIM resources to new LPAR. NIM standalone client objects are created for each new derived LPAR created in phase 4 using the network information provided to nim_move_up. Appropriate NIM resources are allocated and a bos_inst pull operation is run on each NIM client (NIM does not attempt to boot the client).
8. Initiate installation on LPAR. Each LPAR is rebooted using the control host (HMC) and the installation is initiated. The phase's execution stops after the installation has begun (that is, the progress of the installation is not monitored).
9. Assess post-migration software. After each installation has completed, the overall success of the migration is assessed, and a report of software problems encountered during migration is generated. If any filesets failed to migrate, the errors reported for that fileset must be corrected manually.
10. Customize post-installation. If an alternate LPP_Source, fileset list, or customization script was provided, a customized NIM operation is performed on each client with the values provided. This allows for the optional installation of additional software applications or for any additional customization.

To populate the required and optional input through the SMIT interface, enter one of the following commands:

smitty nim_move_up_config

or

smitty nim_move_up

and select the Configure nim_move_up Input Values option.

After the nim_move_up command's environment has been configured with the needed input, those values are remembered through subsequent runs of the nim_move_up command until the nim_move_up command environment is unconfigured. The values can be changed at any time through the SMIT menu interface or by providing the new values through command line flags. The command line interface can also be used to configure the nim_move_up command environment. If you use the command line interface, the nim_move_up command, by default, also attempts to execute phases whenever configuration values are provided to it. To prevent phases from being executed when calling the command directly, use the -O flag.

To start nim_move_up phases through the SMIT interface, type one of the following commands:

smitty nim_move_up_exec

or

smitty nim_move_up

and select the Execute the nim_move_up Phases option. Answer the Execute All Remaining Phases? option and press Enter. The phases begin executing.

To specify that nim_move_up execute only the next phase using the command line, type the following command:

nim_move_up -n

To specify that nim_move_up execute all remaining phases, type the following command:

nim_move_up

In addition to executing phases, this command can also modify saved configuration options if the appropriate flag is supplied.

The nim_move_up SMIT menus can be accessed using the nim_move_up fastpath. To invoke the root menu of nim_move_up, type the following command:

smitty nim_move_up

The following SMIT screens are accessible through the root menu:

Display the Current Status of nim_move_up

Equivalent to running nim_move_up with the -S flag. The next phase to be executed and a listing of all the saved options are displayed.

Configure nim_move_up Input Values

Through this screen, all required and optional input to nim_move_up can be configured. All values entered into the fields are saved and are remembered through subsequent runs of nim_move_up and through subsequent uses of this SMIT screen. This screen can be used at any time to modify saved values after phases have been run.

Execute nim_move_up Phases

Provides a simple interface to execute nim_move_up phases. The phases can be executed one at a time or all at once, depending on how the questions in this phase are answered.

Configure SSH Keys on Target HMC

Provides a simple interface for setting up SSH keys on the remote control host (HMC). This does the equivalent work of passing the -K flag on the command line. Configuring SSH keys on the remote control host enables the unattended remote execution of commands from the NIM master, which is necessary for completing all the phases (some of which remotely execute commands on this system).

Unconfigure nim_move_up

Provides an interface to unconfigure the nim_move_up command's environment. This removes all state information, including which phase to execute next, saved data files generated as a result of the execution of some phases, and all saved input values. Optionally, all NIM resources created through nim_move_up can be removed as well. This screen does the equivalent work of the -r command line option.

The following list describes the purpose and contents of each file in the /var/mig2p5 directory:

config_db

Contains all of the saved configuration options passed to nim_move_up through the command line arguments or the nim_move_up_config SMIT menu. Each line in the file takes the following form:

option_name:value

current_phase

Contains the number of the phase that will be executed at the next invocation of nim_move_up. Before running this phase, nim_move_up ensures that all previous phases have run successfully. This information is also maintained elsewhere with the mig2p5 framework.

global_log

Contains the output of all phases that have been run since the last time the mig2p5 framework was initialized.

client_data/

Contains files that are generated by nim_move_up during phases 3 and 4, in which each of the original clients' system resources and utilization are monitored and quantified into configuration files. The available resources in the POWER server are also quantified into corresponding text files. All the data in these files will be taken into account when determining the hardware profile of the newly derived LPAR on the POWER server. These files are intended to be machine-readable data files for the nim_move_up command's internal use. Do not manually modify or create them.

phase#/

Contains data specific to the corresponding phase denoted by the number in its name ( # ). Every phase has a directory (for example, phase1/ , phase2/ , and so on).

phase#/log

Contains all output displayed during a phase's run. If a phase runs multiple times (such as after an error has been corrected), all new output is appended to any text already existing in the file. This log is helpful in investigating failures related to this phase after they have occurred. The global_log file is composed of all the phases' log files, and all output in that file is arranged in the order that it was originally displayed.

phase#/status

Indicates whether this phase succeeded or failed when it was last run. This file is used by nim_move_up to determine whether a subsequent phase can be run. A phase can run only if all of the previous phases' status files contain the string success. The status file contains the failure string if the phase encountered an error that caused it to fail the last time it was run.

pid

Contains the nim_move_up process ID number when nim_move_up is running in the background. This file and is cleaned up when the process finishes. As long as this file exists and contains a process ID, nim_move_up cannot run phases because concurrent runs of nim_move_up are not supported.

With the exception of the log files and the contents of the client_data/ directory, the files in /var/mig2p5 that comprise the mig2p5 framework can be read and modified so that nim_move_up performs tasks that it would not do through its command line and SMIT interfaces. Users are encouraged to manipulate the mig2p5 environment to make nim_move_up meet any specific need and to aid in the troubleshooting of any problems that might arise during the migration process.

During phase4 of the nim_move_up command, the tool calculates various resource requirements based on the back-level AIX machine and appropriately creates an LPAR on a target POWER server. When you meet any of the following situations, you can specify what modifications you need in the manual configuration file in a predefined format and run the nim_move_up command:

• There is a need for more memory than that determined by the nim_move_up command.
• There is a virtual SCSI adapter (vhost#) created on a Virtual I/O server that you want to use for a Volume Group.
• You want to use a different Virtual Local Area Network (VLAN) ID than the one generated by the nim_move_up tool.

After the successful completion of the nim_move_up command, the manual configuration is applied on the target LPAR.

The following is a sample of the manual configuration file:

# manual_cfgfile_dennis file
# MEMORY = min_MB desired_MB max_MB
MEMORY = 256 512 1024
# VIO_VG_INFO = vgname_src, size_in_MB, vhost_to_use
#    Where vgname_src is the VG name in source machine, and
#    vhost_to_use is the virtual adapter to be used for
#    the VG specified in the VIO Server.
VIO_VG_INFO = rootvg,15344,vhost4
# VIO_VLAN_INFO = vlan_id, lpar_name, slot_number
VIO_VLAN_INFO = 1,VIO-server,2

All of the min_MB, desired_MB, and max_MB values must be in megabytes (MB). There is no restriction on the number of spaces between these numbers.

min_MB

The minimum memory required for AIX to run.

desired_MB

The amount of memory that you want the logical partition to have when activated.

max_MB

The maximum memory when dynamic logical-partitioning operations are performed on the partition.