Copying POWER5 LPARs
Partitioning an IBM POWER5 machine with an HMC is, most of the time, an easy but tiresome task. And when it comes to reproduce the same partitioning scheme on more than one machine, it just takes to much time doing it the "official" way. I'm putting the word "official" in quotes, because I won't be giving you any advice on advanced voodoo tactics to POWER5 partitioning here, but just a different way of cloning partitioning schemes not shown on IBM courses 
The official way to create and distribute partitioning schemes nowadays are system plans. You can create a system plan with IBM's LPAR validation tool before even buying the machine, buy an adequate machine afterwards and deploy that plan to create the partitions needed. While this works reasonably well on one machine and setups which aren't too complicated, it's hell to maintain or adjust to new requirements.
One thing we used over here at the office for some time were those binary partitioning profiles. You can actually save and recover them from the HMC, but using these is a bad idea, because you'll end up with duplicate MAC addresses(Yes, they're stored in that binary profile and they are not re-created when you rebuild a partition from that profile and there's no option to do so).
While this might be good for backup and security purposes(you won't have to alter your MAC access lists when rebuilding partitions after a hardware failure), it's not acceptable when you put up and destroy partitions on a regular basis.
Now that's where the third option, HMC CLI partitioning is getting handy.
Assuming you're only having one POWER5 machine attached to your HMC, this little scriptlet will read your current partitioning data and transform it into a script you can paste into another HMC to get the identical partitioning scheme(WARNING: It will also use the SAME physical resources, so make sure your physical adapters are in the same locations):
The output will look similar to this(but it should be ONE line only):
Actually, this is a bad example, because it would be better to create the Virtual I/O Servers manually, because they rely on physical adapters which might not be in the same position as on the machine you were getting the partitioning data from, but for fully virtualised LPARs, it works like a charm and all you have to do is adjust the name of the Virtual I/O Server in the vSCSI definitions(which could be handled by another script) if you're not using generic names like VIOS for the I/O servers(over here, we use individual names based on the machine, so the command lines have to be adjusted for the individual machine.
But as I said initially, copying partitions this way gives you the possibility to change things and not just copying things over to another machine.
The official way to create and distribute partitioning schemes nowadays are system plans. You can create a system plan with IBM's LPAR validation tool before even buying the machine, buy an adequate machine afterwards and deploy that plan to create the partitions needed. While this works reasonably well on one machine and setups which aren't too complicated, it's hell to maintain or adjust to new requirements.One thing we used over here at the office for some time were those binary partitioning profiles. You can actually save and recover them from the HMC, but using these is a bad idea, because you'll end up with duplicate MAC addresses(Yes, they're stored in that binary profile and they are not re-created when you rebuild a partition from that profile and there's no option to do so).
While this might be good for backup and security purposes(you won't have to alter your MAC access lists when rebuilding partitions after a hardware failure), it's not acceptable when you put up and destroy partitions on a regular basis.
Now that's where the third option, HMC CLI partitioning is getting handy.
Assuming you're only having one POWER5 machine attached to your HMC, this little scriptlet will read your current partitioning data and transform it into a script you can paste into another HMC to get the identical partitioning scheme(WARNING: It will also use the SAME physical resources, so make sure your physical adapters are in the same locations):
for LPAR in $(lssyscfg -r lpar -F lpar_id -m $(lssysconn -r all -F type_model_serial_num)); do
lssyscfg -r prof -m $(lssysconn -r all -F type_model_serial_num) \
--filter "lpar_ids=${LPAR}, profile_names=default" \
| sed -e 's/^name/profile_name/g' \
-e 's/lpar_name/name/g' \
-e 's/"virtual_serial_adapters=.*","virtual_scsi_adapters/"virtual_scsi_adapters/g' \
-e "s/^/mksyscfg -r lpar -m \$\(lssysconn -r all -F type_model_serial_num\) -i '/g" -e "s/$/'/g"
done
The output will look similar to this(but it should be ONE line only):
mksyscfg -r lpar -m $(lssysconn -r all -F type_model_serial_num) -i
'profile_name=default,name=VIOS2,lpar_id=2,lpar_env=vioserver,all_resources=0,
min_mem=128,desired_mem=384,max_mem=512,proc_mode=shared,min_proc_units=0.1,
desired_proc_units=0.2,max_proc_units=0.3,min_procs=1,desired_procs=2,max_procs=2,
sharing_mode=uncap,uncap_weight=128,"io_slots=21020003/none/1,21050002/none/1",
lpar_io_pool_ids=none,max_virtual_slots=10,"virtual_scsi_adapters=4/server/any//any/0,3/server/any//any/0",
virtual_eth_adapters=2/0/2//1/0,boot_mode=norm,conn_monitoring=0,auto_start=0,
power_ctrl_lpar_ids=none,work_group_id=none'
Actually, this is a bad example, because it would be better to create the Virtual I/O Servers manually, because they rely on physical adapters which might not be in the same position as on the machine you were getting the partitioning data from, but for fully virtualised LPARs, it works like a charm and all you have to do is adjust the name of the Virtual I/O Server in the vSCSI definitions(which could be handled by another script) if you're not using generic names like VIOS for the I/O servers(over here, we use individual names based on the machine, so the command lines have to be adjusted for the individual machine.
But as I said initially, copying partitions this way gives you the possibility to change things and not just copying things over to another machine.
