In this section, I'll describe some of the basics behind Big-IP software upgrade operations.
Software images can be installed to any software volume except the running volume. This behavior ensures the running software volume is available should a need arise to revert to the prior Big-IP version and configuration.
It is recommended to install the Big-IP update to an empty software volume to avoid potential confusion should the configuration fail to push to the new software volume.
By default, the current running configuration is pushed to the new software volume automatically.
The 'Install Configuration' option in the Configuration Utility can be used to update the target software volume prior to booting/activating the volume if time has elapsed since the software was installed and some of the Big-IP configuration has changed in the interim. This is generally unnecessary if you install the software and immediately boot into it. For more information, refer to K14704: Installing a configuration when activating a boot location.
For a Big-IP instance, multiple Big-IP software installations can exist on disk. Use the
tmsh show sys software
command to view all software volumes. You can install directly over an existing software volume and the target volume will be overwritten. In order to delete a software volume, you can use the Configuration Utility or tmsh. Software installation can be performed via the Configuration Utility or tmsh. For more information, refer to:
When a Hotfix ISO file is installed, two installations will happen in the background; the first will install the Final (larger) ISO and the second will install the Hotfix ISO. In the GUI, you will see two progress bars progress from 0-100%.
The first boot of the new Big-IP software volume will take extra time, compared to a reboot, in order to decompress packages and to import the running configuration for the first time. Installation progress can be monitored via the serial console port or via the
For Big-IP 10.x to 11.x upgrades, the previous configuration will first appear in the /config/bigpipe/ directory in the new software volume. When the new software volume is first booted, the configuration in /config/bigpipe/ will be converted and copied to the /config/ directory. So, if there are no virtual servers in /config/bigip.conf after upgrading from v10.x, the conversion process from /config/bigpipe/ likely failed for some reason.
High Availability (HA) communication via network failover will function between major software branches but is only supported for the duration of the upgrade process. For example, a pair of Big-IPs running 11.5.3 and 12.1.1 can negotiate Active/Standby status via network failover. For more information, refer to K8665: BIG-IP redundant configuration hardware and software parity requirements.
Configsync will not operate between different major software branches. For example, you cannot synchronize configurations from a unit running 11.5.3 unit to a unit running 11.5.4; you must wait for both units to be upgraded until configsync will operate. For more information, refer to K13946: Troubleshooting ConfigSync and device service clustering issues (11.x - 12.x).
As an alternative method to install the desired software version, prepared USB media can be used to reinitialize the disk and Big-IP software to factory defaults. Once complete, a previously saved UCS archive can be loaded to restore configuration. This method will wipe all data on the system. For more information, refer to:
If the software installation completes and you are able to boot the new volume but the Big-IP configuration fails to be migrated, you may see an error in the Configuration Utility.
The configuration has not yet loaded. If this message persists, it may indicate a configuration problem.
To determine what may be causing the error, run the
tmsh load sys config verify
command.
vCMP considerations
While vCMP guests are their own operating system, they inherit their license from the vCMP host or hypervisor. Before any vCMP guest can be upgraded, the vCMP host license must be reactivated.
When a vCMP Host is upgraded, the Guests will go offline. A Host upgrade will not upgrade individual Guests.
Only upgrade one vCMP Guest at a time to avoid excessive disk and CPU usage.
For a vCMP Host, it is recommended but not required to run the same Big-IP version as the highest version Guest being hosted.
For F5 platforms with multiple blades, software image ISO files are shared between blades. In 11.6.0+, ISO files are also shared from Hosts to Guests.
Hosts and Guests utilize unique UCS configuration files. For instance, a Host UCS file does not contain Big-IP objects (for example, self IP addresses or virtual servers) for the Guests which are installed on the Host.
While vcmp guests are their own system, they do inherit their license from the vcmp host. This means that before any of the vcmp guests can be upgraded, the vcmp host that they run on must have its license reactivated. It is my understanding that the vcmp guests pick up the license from the vcmp host when they boot up.
Why to reactivate license every time before upgrade? Usually it's enough just to check "service check date" and then decide whether license needs to be updated or not. I would avoid unnecessary re-licensing on vCMP Host..
Zdenda, you are correct. K7727 holds the relevant information about whether a reactivation is required or not. License activation is described in more detail in Parts 1 and 3 of this document series.
