Solaris Live Upgrade
provides a method of upgrading a system while the system continues to operate.
While your current boot environment is running, you can duplicate the boot
environment, then upgrade the duplicate. Or, rather than upgrading, you can
install a Solaris Flash archive on a boot environment. The original system
configuration remains fully functional and unaffected by the upgrade or installation
of an archive. When you are ready, you can activate the new boot environment
by rebooting the system. If a failure occurs, you can quickly revert to the
original boot environment with a simple reboot. This switch eliminates the
normal downtime of the test and evaluation process.

Solaris Live Upgrade enables you to duplicate a boot environment without
affecting the currently running system. You can then do the following:

Upgrade a system.

Change the current boot environment's disk configuration to
different file system types, sizes, and layouts on the new boot environment.

Maintain numerous boot environments with different images.
For example, you can create one boot environment that contains current patches
and create another boot environment that contains an Update release.

Some understanding of basic system administration is necessary before
using Solaris Live Upgrade. For background information about system administration
tasks such as managing file systems, mounting, booting, and managing swap,
see the System Administration Guide: Devices and File Systems.

Solaris Live Upgrade Process

The following overview describes the tasks necessary to create
a copy of the current boot environment, upgrade the copy, and switch the upgraded
copy to become the active boot environment. The fallback process of switching
back to the original boot environment is also described. Figure 2–1 describes this
complete Solaris Live Upgrade process.

Figure 2–1 Solaris Live Upgrade Process

The following sections describe the Solaris Live Upgrade process.

A new boot environment can be created on a physical slice
or a logical volume:

Creating a Boot Environment

The process of creating a boot environment
provides a method of copying critical file systems from an active boot environment
to a new boot environment. The disk is reorganized if necessary, file systems
are customized, and the critical file systems are copied to the new boot environment.

File System Types

Solaris Live Upgrade distinguishes between two file system types:
critical file systems and shareable. The following table describes these file
system types.

File System Type

Description

Examples and More Information

Critical file systems

Critical file systems are required by the Solaris OS. These file systems
are separate mount points in the vfstab of the active
and inactive boot environments. These file systems are always copied from
the source to the inactive boot environment. Critical file systems are sometimes
referred to as nonshareable.

Examples are root (/), /usr, /var, or /opt.

Shareable file systems

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.
When you create a new boot environment, shareable file systems are shared
by default. But you can specify a destination slice and then the file systems
are copied.

For UFS file systems, swap is a special shareable volume.
Like a shareable file system, all swap slices are shared by default. But,
if you specify a destination directory for swap, the swap slice is copied.

For ZFS file systems, swap and dump volumes are shared within
the pool.

Creating RAID-1 Volumes on File Systems

Copying File Systems

The process of creating a new boot environment begins by identifying
an unused slice where a critical file system 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.

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. You can also split file systems from their
parent directories by specifying different mount points.

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. The exception
is that you can designate some shareable 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 new directories. The active boot environment
is not changed in any way.

Examples of Creating a New Boot Environment

Figure 2–2 shows
that critical file system root (/) has been copied to
another slice on a disk to create a new boot environment. The active boot
environment contains the root (/) file system on one
slice. The new boot environment is an exact duplicate with the root (/)
file system on a new slice. The /swap volume and /export/home file system are shared by the active and inactive boot environments.

Figure 2–3 shows
critical file systems that have been split and have been copied to slices
on a disk to create a new boot environment. The active boot environment contains
the root (/) file system on one slice. On that slice,
the root (/) file system contains the /usr, /var, and /opt directories. In the new boot
environment, the root (/) file system is split and /usr and /opt are put on separate slices.
The /swap volume and /export/home file
system are shared by both boot environments.

Figure 2–4 shows
critical file systems that have been merged and have been copied to slices
on a disk to create a new boot environment. The active boot environment contains
the root (/) file system, /usr, /var, and /opt with each file system on their
own slice. In the new boot environment, /usr and /opt are
merged into the root (/) file system on one slice. The /swap volume and /export/home file system
are shared by both boot environments.

Creating a Boot Environment With RAID-1 Volume
File Systems

Solaris Live Upgrade uses Solaris Volume Manager technology
to create a boot environment that can contain file systems encapsulated in
RAID-1 volumes. Solaris Volume Manager provides a powerful way to reliably
manage your disks and data by using volumes. Solaris Volume Manager enables
concatenations, stripes, and other complex configurations. Solaris Live Upgrade
enables a subset of these tasks, such as creating a RAID-1 volume for the
root (/) file system.

A volume can group disk slices across several disks to transparently
appear as a single disk to the OS. Solaris Live Upgrade is limited to creating
a boot environment for the root (/) file system that
contains single-slice concatenations inside a RAID-1 volume (mirror). This
limitation is because the boot PROM is restricted to choosing one slice from
which to boot.

How to Manage Volumes With Solaris Live Upgrade

When creating a boot environment, you can use Solaris Live Upgrade to
manage the following tasks.

Detach a single-slice concatenation (submirror) from a RAID-1
volume (mirror). The contents can be preserved to become the content of the
new boot environment if necessary. Because the contents are not copied, the
new boot environment can be quickly created. After the submirror is detached
from the original mirror, the submirror is no longer part of the mirror.
Reads and writes on the submirror are no longer performed through the mirror.

Create a boot environment that contains a mirror.

Attach a maximum of three single-slice concatenations to the
newly created mirror.

You use the lucreate command with the -m option
to create a mirror, detach submirrors, and attach submirrors for the new boot
environment.

Note –

If VxVM volumes are configured on your current system, the lucreate command can create a new boot environment. When the data is copied
to the new boot environment, the Veritas file system configuration is lost
and a UFS file system is created on the new boot environment.

A RAID-0 volume. If slices are concatenated, the data is written to
the first available slice until that slice is full. When that slice is full,
the data is written to the next slice, serially. A concatenation provides
no data redundancy unless it is contained in a mirror.

mirror

A RAID-1 volume. See RAID-1 volume.

RAID-1 volume

A class of volume that replicates data by maintaining multiple copies.
A RAID-1 volume is sometimes called a mirror. A RAID-1 volume is composed
of one or more RAID-0 volumes that are called submirrors.

RAID-0
volume

A class of volume that can be a stripe or a concatenation. These components
are also called submirrors. A stripe or concatenation is the basic building
block for mirrors.

state database

A state database stores information about disk about the state of your
Solaris Volume Manager configuration. The state database is a collection of
multiple, replicated database copies. Each copy is referred to as a state
database replica. The state database tracks the location and status of all
known state database replicas.

state database replica

A copy of a state database. The replica ensures that the data in the
database is valid.

submirror

See RAID-0 volume.

volume

A group of physical slices or other volumes that appear to the system
as a single logical device. A volume is functionally identical to a physical
disk in the view of an application or file system. In some command-line utilities,
a volume is called a metadevice.

Examples of Using Solaris Live Upgrade to Create
RAID-1 Volumes

The following examples present command syntax for creating RAID-1 volumes
for a new boot environment.

Create RAID-1 Volume on Two Physical Disks

Figure 2–5 shows
a new boot environment with a RAID-1 volume (mirror) that is created on two
physical disks. The following command created the new boot environment and
the mirror.

Preserves the contents of concatenation d12.
File systems are not copied.

Creates a new mirror d20. You now have
two one-way mirrors d10 and d20.

Attaches concatenation d12 to mirror d20.

Figure 2–6 Create a Boot Environment
and Use the Existing Submirror

Upgrading a Boot Environment

After you have created a boot environment, you can perform an
upgrade on the boot environment. As part of that upgrade, the boot environment
can contain RAID-1 volumes (mirrors) for any file systems. Or the boot environment
can have non-global zones installed. The upgrade does not affect any files
in the active boot environment. When you are ready, you activate the new boot
environment, which then becomes the current boot environment.

For procedures about upgrading a boot environment for UFS file systems

Figure 2–7 Upgrading an Inactive Boot Environment

Rather than an upgrade, you can install a Solaris Flash archive
on a boot environment. The Solaris Flash installation feature enables
you to create a single reference installation of the Solaris OS on a system.
This system 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. When you install the Solaris Flash archive
on a system, the archive replaces all the files on the existing boot environment
as an initial installation would.

The following figures show an installation of a Solaris Flash archive
on an inactive boot environment. Figure 2–8 shows a system with a single hard disk. Figure 2–9 shows a system
with two hard disks.

Figure 2–8 Installing a Solaris Flash Archive
on a Single Disk

Figure 2–9 Installing a Solaris Flash Archive
on Two Disks

Activating a Boot Environment

When you are ready to switch and make the new boot
environment active, you quickly activate the new boot environment and reboot.
Files are synchronized between boot environments the first time that you boot
a newly created boot environment. “Synchronize” means that certain
system files and directories are copied from the last-active boot environment
to the boot environment being booted. When you reboot the system, the configuration
that you installed on the new boot environment is active. The original boot
environment then becomes an inactive boot environment.

Figure 2–10 shows
a switch after a reboot from an inactive to an active boot environment.

Figure 2–10 Activating an Inactive Boot Environment

Falling Back to the Original Boot Environment

If a failure
occurs, you can quickly fall back to the original boot environment with an
activation and reboot. The use of fallback takes only the time to reboot the
system, which is much quicker than backing up and restoring the original.
The new boot environment that failed to boot is preserved. The failure can
then be analyzed. You can only fall back to the boot environment that was
used by luactivate to activate the new boot environment.

You fall back to the previous boot environment the following ways:

Problem

Action

The new boot environment boots successfully, but you are not happy with
the results.

Run the luactivate command with the name of the previous
boot environment and reboot.

x86 only –

Starting with the Solaris 10
1/06 release, you can fall back by selecting the original boot
environment that is found on the GRUB menu. The original boot environment
and the new boot environment must be based on the GRUB software. Booting from
the GRUB menu does not synchronize files between the old and new boot environments.
For more information about synchronizing files, see Forcing a Synchronization Between Boot Environments.

The new boot environment does not boot.

Boot the fallback boot environment in single-user mode, run the luactivate command, and reboot.