-j identifies the volume group that will be
used on the NIM master to create file systems.

-Y Agrees to required software license
agreements for software to be installed.

-N specifies the name of the new AIX 7.1 NIM
mksysb resource to be created after migration.

Before running this
command I made sure that I had installed the bos.alt_disk_install.rte fileset into my AIX
7.1 SPOT. If this fileset was not installed I would have received the following
message immediately after issuing the nimadm
command:

0042-001 nim: processing error encountered on
"master":

/usr/bin/lslpp: Fileset bos.alt_disk_install.rte not installed.

0505-204 nimadm:
SPOT spotaix7tl0sp2 does not have bos.alt_disk_install.rte installed.

0505-205 nimadm:
The level of bos.alt_disk_install.rte installed in SPOT

spotaix7tl0sp2 (0.0.0.0) does not match the
NIM master's level (7.1.0.2).

Cleaning up alt_disk_migration on the NIM
master.

I also had an AIX 7.1
lpp_source and SPOT ready and waiting on my NIM master.

root@nim1 / # lsnim -t lpp_source

aix61tl6sp3resourceslpp_source

opensshresourceslpp_source

aix7tl0sp2resourceslpp_source

root@nim1 / # lsnim -t spot

vio1-spotresourcesspot

spotaix61tl6sp3resourcesspot

spotaix7tl0sp2resourcesspot

OK, back to my nimadm operation. Upon initiating the
migration I saw the following output on my screen (click here
for a copy of the complete log file):

I didn’t encounter any
issues with my nimadm operation but
if I had I could have reviewed the nimadm
log file located in /var/adm/ras:

root@nim1 /var/adm/ras/alt_mig # ls -ltr

total 856

-rw-r--r--1 rootsystem435009 Jan 06 11:00 cg-aix61_alt_mig.log

If you ever encounter
problems with nimadm, I highly
recommend that you re-run the operation with the –V and –D flags. This will
enable verbose output, as well as debugging information which can assist you
greatly in determining the root cause of your issue.

I was able to use the
new, migrated, AIX 7.1 mksysb image to install a new LPAR.

By the way, if you are
interested in migrating from AIX 4.3 to AIX 7.1, then you’ll need to consider
the mksysb migration method. I’ve not
done this myself (i.e. 4.3 to 7.1 migration) but the feedback I received from
the AIX development team indicates that it does work as expected.

“... you had expressed some interest
in mksysb migration. Since we were not aware of anyone having attempted
it with 7.1. I went ahead and created a 4.3.3.75 system and created a
mksysb and then used that mksysb in conjunction with nim and successfully
installed another system using the 4.3 mksysb and 7.1 nim resources to perform
a mksysb migration to 7.1. I just followed the steps as noted in the
Installation guide for mksysb migration. “

Refer to the following
document for further information on mksysb migration with NIM.

Recent releases of AIX installation media
(for 7.1 and 6.1) now contain the OpenSSH base installation filesets. This is
very handy; we no longer need to download or locate the software from other
sources.

One thing to consider is what this means
for future AIX migrations.

If you are migrating a system (that already
has a version of SSH installed) to AIX 7.1 then you may notice that the first
time you attempt to connect to the server (after the 7.1 migration) the
following ssh message appears:

root@nim1
: / # ssh aixlpar1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@WARNING: REMOTE HOST IDENTIFICATION HAS
CHANGED!@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT
IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone
could be eavesdropping on you right now (man-in-the-middle attack)!

It
is also possible that a host key has just been changed.

The
fingerprint for the RSA key sent by the remote host is

59:68:05:71:60:b5:d1:96:87:df:f6:9c:ca:9a:14:3e.

Please
contact your system administrator.

Add
correct host key in /.ssh/known_hosts to get rid of this message.

Offending
RSA key in /.ssh/known_hosts:17

RSA
host key for aixlpar1 has changed and you have requested strict checking.

Host key
verification failed.

In the
output above I’m attempting to SSH from another system to the newly migrated
AIX 7.1 LPAR. This is essentially informing us that the SSH host keys on the
AIX 7.1 server don’t match the host key stored in the local systems
/.ssh/known_hosts file. Something has changed.

Now of
course I could simply accept this change and update my known_hosts files, like
so:

root@nim1
: / # ssh-keygen -R aixlpar1

/.ssh/known_hosts
updated.

Original
contents retained as /.ssh/known_hosts.old

With
known_hosts updated, I’m able to SSH to the AIX 7.1 system successfully.

cgibson@nim1
: /home/cgibson $ ssh aixlpar1 date

Mon
Aug 20 19:44:20 EET 2012

But that’s
just for my SSH known_hosts file only. What about all the users that connect to
this system via SSH/SFTP/SCP? Do I really expect all of them to update their
known_hosts file with the new host key information?

This could
create problems for automated tasks, like file transfers. If these transfers
stop working then their could be “hell to pay”. So the question I’m often asked
is what can I do to prevent this from happening in the first place? Luckily
there is a way.

In this
example, we are using nimadm to migrate from AIX 5.3 to 7.1. The
AIX 7.1 lpp_source resource was created using the AIX 7.1 installation media
DVDs. All filesets were copied from the DVDs, verbatim, to the new 7.1
lpp_source resource on the NIM master.

First we
verify that the openssh* filesets are in fact in the AIX 7.1 lpp_source on the
NIM master.

root@nim1
: / # nim -o showres lpp_sourceaix710101 | grep -i ssh

openssh.base.client5.4.0.6100IN usr,root

openssh.base.client5.8.0.6101IN usr,root

openssh.base.server5.4.0.6100IN usr,root

openssh.base.server5.8.0.6101IN usr,root

openssh.man.en_US5.4.0.6100IN usr

openssh.man.en_US5.8.0.6101IN usr

openssh.msg.EN_US5.8.0.6101IN usr

openssh.msg.en_US5.4.0.6100IN usr

openssh.msg.en_US5.8.0.6101IN usr

On the NIM
client (running AIX 5.3), we verify there is an older version of SSH already
installed. The migration will remove these filesets (and the associated
/etc/ssh_host_* files). The newer version of SSH will be installed and new
ssh_host_key* files will be generated (hence the problem with the remote SSH
clients known_hosts files no longer holding the correct host keys).

Rather than
update these filesets manually after the migration, you can include this step
as a post migration task with nimadm.

An
alternative way to work around this problem (after the fact) would be to
restore the original ssh_host_key* files from a backup.For example, I copied the original
ssh_host_key* files to my home directory before starting the AIX migration.

aixlpar1
: / # cd /etc

aixlpar1
: /etc # cp -pr ssh /home/cgibson/ssh_orig/

In the
output below, I discover that my ssh_host_key* files have all been recreated
during the migration.

aixlpar1
: /etc/ssh # ls -ltr

total
352

-rw-r--r--1 rootsystem1288 May 01
2007ssh_config

-rw-r--r--1 rootsystem1155 May 04
2007sshd_banner

-rw-r--r--1 rootsystem2867 Oct 29
2008sshd_config

-rw-r-----1 rootsystem7 Aug 20 21:00
sshd.pid

-rw-r--r--1 rootsystem2341 Aug 20 21:19
ssh_prng_cmds

-rw-------1 rootsystem132839 Aug 20 21:19
moduli

-rw-r-----1 rootsystem382 Aug 20 21:45
ssh_host_rsa_key.pub

-rw-------1 rootsystem1679 Aug 20 21:45
ssh_host_rsa_key

-rw-r-----1 rootsystem630 Aug 20 21:45
ssh_host_key.pub

-rw-------1 rootsystem965 Aug 20 21:45
ssh_host_key

-rw-r-----1 rootsystem590 Aug 20 21:45
ssh_host_dsa_key.pub

-rw-------1 rootsystem668 Aug 20 21:45
ssh_host_dsa_key

I copy the
original files back to the /etc/ssh directory. The sshd subsystem is also
restarted to pick up the updated ssh_host* files.

aixlpar1
: /etc/ssh # cp -p /home/cgibson/ssh_orig/ssh_host_* .

aixlpar1
: /etc/ssh # ls -ltr

total
352

-rw-r--r--1 rootsystem210 Feb 03
2006ssh_host_rsa_key.pub

-rw-------1 rootsystem887 Feb 03 2006ssh_host_rsa_key

-rw-r--r--1 rootsystem319 Feb 03
2006ssh_host_key.pub

-rw-------1 rootsystem515 Feb 03
2006ssh_host_key

-rw-r--r--1 rootsystem590 Feb 03
2006ssh_host_dsa_key.pub

-rw-------1 rootsystem668 Feb 03
2006ssh_host_dsa_key

-rw-r--r--1 rootsystem1288 May 01
2007ssh_config

-rw-r--r--1 rootsystem1155 May 04
2007sshd_banner

-rw-r--r--1 rootsystem2867 Oct 29 2008sshd_config

-rw-r-----1 rootsystem7 Aug 20 21:00
sshd.pid

-rw-r--r--1 rootsystem2341 Aug 20 21:19
ssh_prng_cmds

-rw-------1 rootsystem132839 Aug 20 21:19
moduli

aixlpar1
: /etc/ssh # stopsrc -s sshd

0513-044
The sshd Subsystem was requested to stop.

aixlpar1
: /etc/ssh # startsrc -s sshd

0513-059
The sshd Subsystem has been started. Subsystem PID is 3997822.

I’ve
written about multibos before, here and here. But recently I
started experimenting with multibos mksysb migration. A customer asked me how
this worked and apart from a high-level view I wasn’t able to provide any real
world experience, so I thought I’d give it a try. What follows is just a ‘brain
dump’ from my quick test.

First of all
this isn’t really a migration. It just simply populates a second instance of
AIX with a higher-version. It doesn’t really migrate (or merge) your existing
configuration into the second instance. So I’m not sure how useful this feature
really is right now.

Starting with
5.3 TL9 you can add a 6.1 TL2 (or above) instance. This is done with the new –M
flag. You must be running with the 64bit kernel.

This isn’t really a migration because it populates the second instance using a
mksysb based on the new release.

In 6.1 TL2 a new flag (-M) was added to the mksysb command which allows you to
create a mksysb for use with multibos. It creates a backup of BOS (/, /usr,
/var, /opt).
bos.alt_disk_install.boot_images must be installed.

It is not advised to run in this environment for an extended period of time.
There could be problems if tfactor or maps are used. Be aware that 6.1 specific
attributes may not be reflected in the standby instance.

So in my
lab environment I have two AIX LPARs. One is running AIX 6.1 and the other
running AIX 7.1.

First I
take a mksysb (with the –M flag) of the AIX 7.1 system to a file. This file
will be called by multibos to populate the second instance.

aix7[/] > mksysb -Mie /data/aix7-mksysb

Creating information file
(/image.data) for rootvg.

Creating list of files to back up.

Backing up 71643 files.....

71643 of 71643 files (100%)

0512-038 mksysb: Backup Completed
Successfully.

aix7[/] > ls -ltr /data

total 4276112

drwxr-xr-x2 rootsystem256 Feb 21 20:59
lost+found

-rw-r--r--1 rootsystem2189363200 Feb 21 21:06
aix7-mksysb

I copied this
file over to my AIX 6.1 system. This was the system that was to be ‘migrated’.
The next step was to perform a preview of the multibos operation.

Upon
checking my bootlist output, I
noticed (as expected) that the list now contained two extra entries for bos_hd5. These were the boot logical
volume entries for the second instance. If I was to boot from this LV I’d be
booting into AIX 7.1. Cool.

root@aix6 /# bootlist -m normal -o

hdisk0 blv=bos_hd5

hdisk0 blv=bos_hd5

hdisk0 blv=hd5

hdisk0 blv=hd5

So at this
point, I’d created a second instance of AIX running 7.1. My current version of
(running) AIX was AIX 6.1. All I had to do now was reboot the LPAR and let it
restart as an AIX 7.1 system.

root@aix6 /# oslevel -s

6100-01-05-0920

root@aix6 / # shutdown –Fr

The LPAR
rebooted successfully and I found I was now running AIX 7.1, just as I’d hoped.

aix6[/] > oslevel -s

7100-00-01-1037

If I wanted
to go back to AIX 6.1, I would change my bootlist setting again and restart the
LPAR.

Now that
I’ve actually tried this method of migration, I’m not sure I’d actually use it
in its current form.

Although
the migration keeps my hostname and IP address, the file systems are not shared
between instances. Most of the target systems configuration is not retained.
For example, any user accounts I create on my AIX 6.1 system would also need to
be created on the existing AIX.7.1 system which I used to create the AIX 7.1
mksysb image. It reminds me a little of a preservation install.