Best practices for the Live Update function

Review these best practices before you start the AIX® Live Update operation.

When you run the Live Update operation, the current configuration of the Virtual I/O Server (VIOS) partitions are modified while the adapters are moved to the surrogate partition. Therefore, it is recommended to turn on the Sync current configuration option so that the current profile also gets updated. If the current profile is not being synchronized, use caution when you restart any VIOS partitions. If the configuration is modified, and you start a VIOS partition from a profile that does not match the current configuration, the AIX partitions might lose access to their adapters.
Before you run the Live Update operation, save a copy of the current partition profiles on the Hardware Management Console (HMC) so that all the information is backed up in case it is needed in the future.
If you plan to install updates by using the Live Update function, the updates are always committed. A copy of the system without the updates is not saved automatically. You must always take a viable backup of the system by using commands such as alt_disk_copy or mksysb before you apply updates so that you can return to the previous level if required.

If you are using vSCSI disks and create a backup copy (alt_rootvg) of the root volume group (rootvg), the AIX Live Update operation might change the Logical Unit Addresses (LUA) of the disks. In this scenario, if you boot from the backup copy (alt_rootvg), the lspath command might display the disk paths that are missing. The disk paths that are missing were associated with the old LUA values. The missing disk paths do not cause any functional problems. You can run the rmpath command to remove the disk paths and have the same number of disk paths that you had before you ran the Live Update operation. The following example displays the missing disk paths and running the rmpath command to remove the disk paths:

root@AIXmig / # lspath
Enabled hdisk5 vscsi1
Enabled hdisk3 vscsi1
Enabled hdisk4 vscsi1
Enabled hdisk0 vscsi1
Enabled hdisk1 vscsi1
Enabled hdisk2 vscsi1
Missing hdisk5 vscsi2
Enabled hdisk3 vscsi2
Missing hdisk4 vscsi2
Missing hdisk0 vscsi2
Enabled hdisk1 vscsi2
Missing hdisk2 vscsi2
Enabled hdisk6 vscsi1
Missing hdisk6 vscsi2
Enabled hdisk6 vscsi2
Enabled hdisk0 vscsi2
Enabled hdisk2 vscsi2
Enabled hdisk4 vscsi2

root@AIXmig / # rmpath -dl hdisk0 -p vscsi2
paths Deleted
root@AIXmig / # rmpath -dl hdisk2 -p vscsi2
paths Deleted
root@AIXmig / # rmpath -dl hdisk4 -p vscsi2
paths Deleted
root@AIXmig / # rmpath -dl hdisk5 -p vscsi2
paths Deleted
root@AIXmig / # rmpath -dl hdisk6 -p vscsi2
paths Deleted

If you are using thin-provisioned Shared Storage Pool (SSP) storage, you must ensure that adequate real storage is available before you start a Live Update operation. The Live Update operation clones the root volume group that is used currently, and then creates a mirror copy of the root volume group that is used currently. If adequate real storage is not available, the Live Update operation fails.
If you run the Live Update operation with a destination that is specified in the lvupdate.data file, then the partition might be temporarily moved to a different managed system. To preserve network connectivity during this timeframe, all VLANs that are used on the partition must be supported by the physical network.
If a Live Update operation fails, it automatically attempts to clean up the system. When the default cleanup fails, the following message prompts the user to run the clvupdate command:
```
1430-115 Warning: Cleanup from the Live Update failure might not have been successful. Run clvupdate to finish the cleanup.
```
If you are prompted with a warning message, run the clvupdate command to clean up the system before you attempt the Live Update operation again. Depending on the exact condition, the clvupdate command prompts the user with a set of actions to take to complete the cleanup.

Best practices for Live Update in PowerVC management

Review these best practices before you start the AIX Live Update operation on a partition that is managed by IBM® Power® Virtualization Center (PowerVC).

If you plan to use the Live Update function on a partition that is managed by PowerVC, a backup copy of the system image without the interim fixes or updates is not saved automatically. You must always take a viable backup of the system image by using commands such as alt_disk_copy or mksysb before you apply updates so that you can return to the previous level of the system, if required.
If an existing logical partition must be managed by PowerVC, verify that the boot volumes are set properly before you attempt a Live Update operation on the logical partition. When PowerVC imports the logical partition, PowerVC might not mark the correct volumes as boot volumes. Incorrect boot volumes can cause unexpected results when logical partitions are rebooted and can also cause the Live Update operation to fail.
If you plan to use the Live Update function on a partition that is managed by PowerVC, you must set the network_allocate_retries property to a minimum value of 10 on the PowerVC. This property must be specified in the /etc/nova/nova.conf file on the PowerVC. If the property is not present in the file, you must add this property as a new line as shown in the following example:
```
network_allocate_retries = 60
```
When a PowerVC-based Live Update function clones a VM, the clone operation fails if the cloned VM attempts to have the same name as the original VM. Complete the following steps to correct this issue:
1. Edit the /etc/nova/nova-XXX.conf file.
2. Update the instance_name_template property as shown in the following sample:
```
instance_name_template = %(display_name).13s-%(uuid).8s -%(id)08x
```
3. Restart the Nova service on PowerVC by running the following command:
```
/opt/ibm/powervc/bin/powervc-services nova restart
```
4. Perform the Live Update operation.

You can refer the PowerVC scalability configuration details for scalable environments.