I’ve been working with a customer recently on
an issue with nimadm. They were
attempting to migrate a system from AIX 5.3 to 7.1 using nimadm. The NIM client AIX
level was 5.3 TL12 SP4 and the NIM master was running AIX 7.1 TL1 SP1.

Given that the error appeared to be related to init_multibos, we assumed the failure was due to some multibos checks being performed by alt_disk_copy on the client. The client
system did not have an existing multibos
standby instance. So, we tried two things: First we created a standby instance
on the client (multibos –s –X) and
re-tried the nimadm operation. This
failed. Next we removed the standby instance (multibos –R) and re-tried the nimadm
operation. This worked and the client then migrated to AIX 7.1 successfully. We
re-tried the same operations (i.e. create standby instance, remove standby
instance & nimadm) several times and each worked as expected.

So it appeared that the unofficial work around to this problem would
be to create and then remove a standby multibos instance prior to the nimadm migrate. However, the customer
has over 200 LPARs that they need to migrate to AIX 7.1. If possible they would
really rather avoid this extra step in the AIX 7.1 migration plan. We’ve made
contact with IBM support and are hoping they can assist us in identifying the
root cause of the issue and provide us with an official solution to the
problem.

And just yesterday we hit the same problem when migrating from AIX 6.1
to 7.1 using nimadm. I’ll update my
blog with any progress we make with this problem. In the meantime, our
unofficial work around will get us “out of hot water”!

UPDATE (14/12/2011): The simple fix is to remove the /bos_inst directory before attempting
the AIX migration. i.e.

If you have a multibos image in rootvg, remove it. AIX
migrations are not
supported with multibos enabled systems. Ensure all rootvg LVs are
renamed to their legacy names. If necessary, create a new instance of
rootvg and reboot the LPAR. For example:

# multibos
–sXp

# multibos
–sX

# shutdown
–Fr

Confirm the legacy LV names are now
in use that is, not bos_.

# lsvg -l
rootvg | grep hd | grep open

hd6paging801602open/syncdN/A

hd8jfs2log122open/syncdN/A

hd4jfs2122open/syncd/

hd2jfs27142open/syncd/usr

hd3jfs216322open/syncd/tmp

hd1jfs2122open/syncd/home

hd9varjfs28162open/syncd/var

hd7sysdump881open/syncdN/A

hd7asysdump881open/syncdN/A

hd10optjfs28162open/syncd/opt

Remove the old multibos instance.

# multibos -R

Unfortunately, it appears that ‘multibos
–R’ may not clean up the /bos_inst directory. If this directory exists the
nimadm operation will most likely fail.