Solaris Live Upgrade provides a method of upgrading that substantially reduces the usual service outage that is associated with an operating system upgrade. You can duplicate your current running boot environment, then while the original boot environment continues to run, you can upgrade the duplicate. Or, rather than upgrading, you can install a Web Start Flash archive on a boot environment. The original system configuration remains fully functional and unaffected by the upgrade or installation of a Web Start Flash archive. The duplicate boot environment is then activated to become the active boot environment when the system is rebooted. If a failure occurs, you have a safety net. You can quickly fall back to the original boot environment with a simple reboot, thereby eliminating the service outages that are associated with the normal test and evaluation process.
Solaris Live Upgrade enables you to migrate a boot environment to have different file system types, sizes, and layouts, without affecting the configuration of the installation software. You can also maintain on your system multiple installations of software packages, including Solaris operating system packages.
For more information about installing and creating Web Start Flash archives, see “Web Start Flash Installation Feature Topics” in Solaris 8 Advanced Installation Guide.
Some understanding of basic system administration is necessary before using Solaris Live Upgrade. For background information on system administration tasks such as managing file systems, mounting, booting, and managing swap, see the System Administration Guide, Volume 1.
Solaris Live Upgrade distinguishes between two file system types: critical file systems and shareable file systems. Critical file systems are required by the Solaris operating environment and are separate mount points in the vfstab of the active and inactive boot environments. Examples are root (/) /usr, /var or /opt. These file systems are always copied from the source to the inactive boot environment. Shareable file systems are user-defined files such as /export that contain the same mount point in the vfstab in both the active and inactive boot environments. Therefore, updating shared files in the active boot environment also updates data in the inactive boot environment. Shareable file systems are shared by default, but you can specify a destination slice and then the file systems are copied.
Swap is a special case of a shareable file system. Like a shareable file system, all files are shared by default. But, like a critical file system, you can split and merge swap slices. You do this by using the character user interface or at the command line by using lucreate with the -m option. A limitation to splitting and merging swap slices is that the swap slice cannot be in use by any boot environment except the current boot environment or if the -s option is used, the source boot environment. The boot environment creation fails if the swap slice is being used by any other boot environment whether the slice contains a swap, ufs, or any other file system. A swap slice is not required. For procedures on reconfiguring swap, see the procedure, “To Create a Boot Environment (Character Interface)” Step 9, or To Create a Boot Environment and Reconfigure Swap (Command-Line Interface).
Creating an inactive boot environment entails copying critical file systems to another slice. First you identify an unused slice where the critical file systems can be copied. If a slice is not available or a slice does not meet the minimum requirements, you need to format a new slice. For the procedure on formatting a slice from menus, see the procedure, “To Create a Boot Environment (Character Interface),” Step 6.
After the slice is defined, you can reconfigure the file systems on the new boot environment before the file systems are copied into the directories. You reconfigure file systems by splitting and merging them, which provides a simple way of editing the vfstab to connect and disconnect file system directories. You can merge file systems into their parent directories by specifying the same mount point or you can split file systems from their parent directories by specifying different mount points. For procedures on splitting and merging file systems, see the procedure, “To Create a Boot Environment (Character Interface)” Step 7 or Step 8 or To Create a Boot Environment and Split File Systems (Command-Line Interface) or To Create a Boot Environment and Merge File Systems (Command-Line Interface).
When you create file systems for a boot environment, the rules are identical to the rules for creating file systems for the Solaris operating environment. Solaris Live Upgrade cannot prevent you from making invalid configurations on critical file systems. For example, you could enter a lucreate command that would create separate file systems for root (/) and /kernel—an invalid division of root (/).
After file systems are configured on the inactive boot environment, you begin the automatic copy. Critical file systems are copied to the designated directories. Shareable file systems are not copied, but are shared (unless you have designated some file systems to be copied). When the file systems are copied from the active to the inactive boot environment, the files are directed to the newly defined directories. Files are synchronized (in a limited way) and the active boot environment is not changed in any way.
Figure 1–1 shows critical file systems that have been copied to a new boot environment. The root (/) file system, as well as any file systems such as /usr, /var, or /opt are copied. File systems such as /export/home are shared by the active and inactive boot environments. For procedures on creating a new boot environment, see Creating a New Boot Environment.
After you have created a boot environment, it remains unchanged until you are ready to upgrade it. You can perform an upgrade on the boot environment at any time. The upgrade does not affect any files in the active boot environment. When you are ready, you then activate to the new release. Figure 1–2 shows an upgrade to an inactive boot environment. For procedures on upgrading a boot environment, see Chapter 4, Upgrading With Solaris Live Upgrade.
Rather than upgrading, you can install a Web Start Flash archive on a boot environment. The Web Start Flash installation feature enables you to create a single reference installation of the Solaris operating environment on a system that is called the master system. Then you can replicate that installation on a number of systems that are called clone systems. In this situation, the inactive boot environment is a clone. For more information about the Web Start Flash installation feature, see “Web Start Flash Installation Feature Topics” in Solaris 8 Advanced Installation Guide.
When you install the Web Start Flash archive on a system, all the files in the archive are copied to that system and a new release is created without affecting the active boot environment. But, unlike an upgrade which merges files, installing a Web Start Flash archive overwrites the files as an initial installation would. Figure 1–3 shows an installation of a Web Start Flash archive on an inactive boot environment. For procedures on installing a Web Start Flash archive, see Installing Web Start Flash Archives on a Boot Environment.
When you are ready to switch and make the boot environment active, you simply activate and reboot. Activating the inactive boot environment modifies it to make it bootable and synchronizes files. When you reboot the system, the configuration that you installed on the inactive boot environment is active. The original boot environment then becomes an inactive boot environment. Figure 1–4 shows a switch after a reboot from an inactive to an active boot environment. For procedures on activating a boot environment, see Activating a Boot Environment .
If a failure occurs, you can quickly fall back to the original boot environment with an activation and reboot. You need to fall back if the inactive boot environment cannot be booted, or if the environment boots but does not work completely, or you are not satisfied with the results.
The use of fallback rather than a backup and restore of the original takes only the time to reboot the system. The active boot environment is saved and the failure can be analyzed. You can only fall back to the last activated boot environment. To fallback, you need to find the slice that contains the root (/) file system mounted on the last boot environment that was activated. You either run luactivate at the command line and then reboot or boot from another media, mount the root (/) file system and run luactivate on the boot environment you want to fallback to, and reboot. Figure 1–5 shows the switch that is made when you reboot to fallback. For procedures to fallback, see Failure Recovery: Falling Back to the Original Boot Environment (Command-Line Interface).
You can also do various maintenance activities such as renaming or deleting a boot environment. For maintenance procedures, see Chapter 5, Maintaining Solaris Live Upgrade Boot Environments.