Live Partition Mobility (LPM) - frustrating validation failure HSCLA27C
nagger 100000MRSJ Comment (1) Visits (23223)
I have been using Shared Storage Pools phase 2 (SSP2) on the beta test a lot recently and it works well - I am very impressed. One key side effect of SSP2 is that it really makes Live Partition Mobility (LPM) very simple and safe.
But then I hit a problem that stumped me - nothing to do with the SSP2 technology - it was just that I in the Advanced Technical Support group have got rusty in setting up and using LPM.
The first problem that most people hit is that the source and target Power machines must have the same LMB size - the what?? Logical Memory Block - this is the memory chunk size that the Hypervisor allocates memory in for use to VIOS and Virtual Machines - I like to think of it in money terms as the smallest change size. This is set in the HMC then ASMI menu Performance Setup tab - the default is very roughly something like one thousandth of your memory. If you have a wide variety of memory sizes on your machines you are going to have to decide a common size. By luck I had remembered that problem and we have ATS policy of LMB size of 128 MB and got that consistent on all machines as we have a planned power outage two months ago - it takes a cold machine boot to get this set.
Log in with your Service Processor (FSP) user/password - that is the "admin" user - fingers crossed that you have remember the password when you initially setup the machine!
Then take the Performance and Logical Memory Block menu
Change, if necessary, but don't forget the Shutdown the whole machine and restart it to make the new size active.
Because of the painful machine reboot, it is recommended to get this LMB Size correct during initial machine setup.
Once I created my SSP2 virtual machine and installed AIX 7 TL1, I tried Mobility to another machine in the SSP2 cluster and it failed for two reasons.
1) I tried the Live Partition Mobility (LPM) from the HMC - just a reminder of where to find this on the HMC see below - my Virtual Machine is called diamond5:
and then clicked through the various options and got the following during the LPM Validation check:
HSCLA27C The operation to get the physical device location for adapter U823
Definitely, not the most helpful message I have seen and the HMC is generally pretty good. If you run that migmgr command on the VIOS as the root user, then you will find it runs OK and returns an "80" on the screen. Hmmm!! Not helpfully either. Next, I decided that there must be a problem with that VIOS resource (U82
Two things to note here:
A) The vdis
B) The vtopt0 which is the VIOS virtual optical media device, which contains the ISO image /var
Arh!! Of course, the virtual optical device is a physical device - it is a file on the VIOS. We can't Migrate a virtual machine with a physical device attached (it has to be pure virtual = virtual network and virtual disks) and this is what is stopping LPM.
So on the VIOS, I removed the vtopt0 device with the padmin command: rmdev -dev vtopt0
2) That fixed the above problem but then I immediately hit the next issue which, again, is caused by me getting rusty as I have not used LPM for a year or two - my colleague in ATS does the LPM demo's. Well that is my excuse :-) The LPM Validation failed this time as it could not find on the target machine the same virtual Ethernet port number on a VIOS. To point out the number I mean, see below:
So I fixed this up on my target machine - I had just I got sloppy on my "crash and burn" demonstration machines and was using various port numbers.
The next Live Partition Mobility (LPM) worked perfectly and I am good to go for all future Shared Storage Pool virtual machines and can move the SSP based virtual machines to any of the four machines in the SSP cluster at will.
Thanks, Nigel Griffiths