maintaining solaris systems with solaris live upgrade and ...€¦ · 1 maintaining solaris with...

An Archived Oracle Technical Paper September 2009

Maintaining Solaris Systems with Solaris Live Upgrade and Update on Attach

Important note: this paper was originally published before the acquisition of Sun Microsystems by Oracle in 2010. The original paper is enclosed and distributed as-is. It refers to products that are no longer sold and references technologies that have since been re-named.

An Archived Oracle Technical Paper

Part NoRevision 1.0, 09/03/09Part No 821-0247-10Revision 1.0, 09/03/09

Maintaining SolariS™ SySteMSwith SolariS live Upgrade and Update on attachHartmut Streppel, Sun MicrosystemsDirk Augustin, Sun MicrosystemsMartin Müller, Sun Microsystems

Sun BluePrints™ Online


Sun Microsystems, Inc.

Contents

Maintaining Solaris Systems with Solaris live Upgrade and Update on attach ..... 1

Minimizing Disruption When Upgrading the Solaris OS ......................................... 2

Patch Management with Sun™ xVM Ops Center ..................................................... 2

Using Solaris live Upgrade ..............................................................................3

Using a ZFS™ File System with Solaris Live Upgrade ............................................... 3

Synchronization in Solaris Live Upgrade ............................................................... 4

Commands Overview ........................................................................................... 4

A Simple Solaris Live Upgrade Example ................................................................5

Creating and Configuring the New Boot Environment ........................................ 5

Applying Patches to the New Boot Environment ................................................ 5

Activating the New Boot Environment .............................................................. 6

Methods for Patching and Upgrading Solaris Cluster Nodes ................................... 7

Standard Upgrade ........................................................................................... 7

Rolling Upgrade .............................................................................................. 8

Dual-Partition Upgrade .................................................................................... 8

Using Solaris Update on attach ...................................................................... 10

Commands Overview ......................................................................................... 10

Update on Attach Examples ............................................................................... 11

Limitations of the Update on Attach Feature ................................................... 12

Moving the Local Zones ..................................................................................... 12

Shutting Down and Exporting the Local Zones ................................................ 12

Importing the Local Zones ............................................................................. 14

Rolling Back the Updated Local Zones ............................................................ 17

Update on Attach in a Solaris Cluster Environment .............................................. 18

The Sample Configuration ............................................................................. 18

Failover Zones ............................................................................................... 19

Update Procedure Overview........................................................................... 20

Upgrading the First Cluster Node ................................................................... 20

Running the Update on Attach Feature ........................................................... 22

Bringing the Failover Zone Back Under Cluster Control .................................... 23

Upgrading the Second Node .......................................................................... 25

Conclusion ................................................................................................... 27

About the Authors ............................................................................................. 27

Acknowledgments ............................................................................................ 27

References ........................................................................................................ 28

Ordering Sun Documents................................................................................... 29

Accessing Sun Documentation Online ................................................................ 29


Sun Microsystems, Inc.

appendix ..................................................................................................... 30

Output of the lucreate Command ................................................................. 30

Output of the luupgrade Command ............................................................... 30

Output of the luactivate Command ............................................................. 32


Sun Microsystems, Inc.1 Maintaining Solaris with Live Upgrade and Update On Attach

.

1

1. The terms Solaris Container and Solaris Zone are interchangeable. For consistency, the termed used throughout this BluePrint article is Solaris Zone or simply zone, however, other documentation both from Sun and other sources might use Solaris Container or container in similar contexts.

Chapter 1

Maintaining Solaris Systems with Solaris live Upgrade and Update on attach

The improved reliability of current systems means that unplanned downtime is

rare. In contrast, planned downtime is considered almost unavoidable, and it is

estimated that over 90% of application downtime is planned. While some planned

downtime can be attributed to hardware issues, maintaining, upgrading, and

replacing application and system software typically accounts for most of the planned

downtime. Solaris™ Live Upgrade and the Solaris update on attach feature can

each reduce the planned downtime required for operating system and application

software upgrades.

This Sun BluePrints™ article explains how to use Solaris Live Upgrade and the Solaris

update on attach feature, with Solaris Zones1, Solaris Cluster, and the ZFS™ file

system for software maintenance in general and the application of operating system

patches in particular.

The article addresses the following topics:

• “Using Solaris Live Upgrade” on page 3, explains how to upgrade standard or

clustered systems using Solaris Live Upgrade.

• “Using Solaris Update on Attach” on page 10, explains how to upgrade standard or

clustered systems using the Solaris update on attach feature.

This article is targeted at Solaris system administrators, infrastructure architects,

datacenter architects, and anyone who requires detailed knowledge of nondisruptive

upgrade techniques and technologies in the Solaris Operating System (OS). The

article expands on information currently available on upgrading the Solaris OS

and assumes a familiarity with Solaris 10 OS, the ZFS file system, and Solaris

Zones. In addition, it covers topics that are only relevant for those familiar with the

deployment of Solaris systems clustered with Solaris Cluster software.

Note: In the case of failure, the procedures described in this Sun BluePrints article can result in data loss. To avoid unintentional disruption to production systems, the following precautions are recommended:

• Backup all data before running any of the examples or commands

• Use ZFS snapshots to save current state prior to running any of the procedures, to help roll-back in case of failure

• Test the procedures first on test systems that are identical to the production systems



.

Minimizing Disruption When Upgrading the Solaris oSUsing traditional techniques, upgrading the operating environment in a production

system can cause application downtime, since the upgrade usually requires system

downtime. With Solaris Live Upgrade and the update on attach feature available as

standard features of the Solaris OS, system downtime is minimized because most

of the upgrade is executed without affecting the functionality of the operating

environment. Downtime due to upgrade failures is also minimized when the ZFS file

system snapshots are used due to the fact that the system can easily be reverted to

its previous state, if required.

Solaris Live Upgrade enables Solaris Operating Systems (versions 2.6, 7, 8, 9, and 10)

to continue to run while an administrator upgrades to a later release of the OS. It

includes the capability to create and modify an inactive duplicate boot environment

and perform maintenance tasks — such as installing patches — while the primary

environment continues to run undisturbed. The duplicate boot environment is

then designated as the active boot environment and the changes are activated by

rebooting the system.

With the update on attach feature, available with Solaris 10 10/08 (Update 6) or

later, a local zone can be updated automatically when it is attached to a global zone

following the migration of the local zone between systems. The update on attach

feature relies on Solaris Zones.

The increasing deployment of virtualization technologies enable business critical

applications to be isolated from the underlying hardware and run transparently on

different servers. This flexibility allows administrators to further reduce application

downtime — both planned and unplanned, by moving applications to run on

alternative servers when executing an upgrade of their usual platform.

Patch Management with Sun™ xVM ops CenterComparing and reconciling patch levels is essential to successfully upgrading and

maintaining systems with multiple virtual operating system environments, using

Solaris Live Upgrade and the update on attach feature. This is true irrespective of

whether the environments are in standalone, consolidated, virtualized, shared

storage, or clustered configurations, or any combination thereof.

At the time of writing, Sun xVM Ops Center does not support the complex patch and

upgrade scenarios described in this Sun BluePrints article.



.

Chapter 2

Using Solaris live Upgrade

Solaris Live Upgrade enables system administrators to create and upgrade a boot

environment that is initially inactive, without affecting the running system. The

inactive boot environment is created with the zones it contains. Once created, the

inactive boot environment is upgraded, and the necessary patches and packages are

installed. The inactive boot environment can then be designated as the active boot

environment, and when the system is next rebooted, it is booted using the newly

created boot environment with no additional downtime.

Before running Solaris Live Upgrade and creating a new boot environment, the

Solaris Live Upgrade packages that match the target version of the OS must be

installed on the system to be updated, with the latest release of the appropriate

patches. Further details are available in “Installation Guide: Solaris Live Upgrade and

Upgrade Planning” in the Solaris installation guide relevant to the target version of

Solaris. See “References” on page 28 for a link to this article for Solaris 10 5/09.

Note: It is essential that the appropriate version of Solaris Live Upgrade, including the latest applicable patches, is installed prior to running any of the examples described in this article.

Two common use-cases for Solaris Live Upgrade are described in this chapter:

• A system that boots from a ZFS file system, including a detailed example

• A clustered environment that requires minimal downtime

Note: While Live Upgrade with Solaris Cluster is generally supported, it cannot be used at the time of writing with Solaris Cluster systems that boot from a ZFS root file system. This restriction is expected to be removed in a later release. See “References” on page 28 for a link to instructions for performing a Live Upgrade to a Solaris Cluster system which does not boot from a ZFS root file system.

Using a ZFS™ File System with Solaris live UpgradeThe ZFS file system is used in this example, since Solaris Live Upgrade can use ZFS

file system clones for the boot environment file systems. ZFS file system clones are

writable ZFS file system snapshots that can be created almost instantaneously and

consume virtually no disk space. While Solaris Live Upgrade can be used with other

file systems, creating a boot environment on a file system other than the ZFS file

system, is likely to take a very long time. This is due to the fact that when a ZFS file

system is cloned, a file-block is copied only when its contents are updated while the

cloning of any other file system requires that each file system block be physically

copied to the clone when it is created.



.

Synchronization in Solaris live UpgradeSolaris Live Upgrade maintains the administrative integrity of the system when

the newly activated boot environment is booted by copying critical files and

directories that have changed between the creation of the newly activated boot

environment and the time the system is booted from it. These files are listed in

/etc/lu/synclist. This process is called synchronization, and is meant for files

such as /etc/passwd or /etc/group. Despite the synchronization process, once

the alternative boot environment is created, it is not advisable to apply critical

changes to the operating environment until the new boot environment is activated.

Commands overviewSolaris Live Upgrade consists of a set of Solaris commands to manage boot

environments. These commands are listed in Table 1.

Table 1. Solaris Live Upgrade commands

command Functionality

lucreate Create a new boot environment, based on the current or other boot

environment, join or separate the file systems of a boot environment

onto a new boot environment, specify separate file systems belonging to

a particular zone inside of the new boot environment, and create the file

systems for a boot environment

luactivate Activate the specified boot environment by making the boot environment’s

root partition bootable

lucompare Compare the contents of the current boot environment with another boot

environment

lucurr Display the name of the currently running boot environment

ludelete Delete all records associated with a boot environment

ludesc Create or update boot environment descriptions created with ludesc or

lucreate

lufslist List the configuration of a boot environment

lumake Populate the file systems of a specified boot environment

lumount,

luumount

Mount or unmount the boot environment’s file systems to access the boot

environment’s files while the boot environment is not active

lurename Rename the boot environment

lustatus Display the status information for boot environments

luupgrade Install software on a boot environment — upgrade an operating system

image, extract a Solaris Flash archive onto a boot environment, add or

remove a package or patch to or from a boot environment, check or obtain

information about packages

Note: In the past, the lu(1M) command provided a Forms and Menu Language Interpreter (FMLI) based user interface for Solaris Live Upgrade administration. While it is still present in Solaris 10, Sun no longer recommends using the lu command.



.

a Simple Solaris live Upgrade exampleIn the following simple example, a ZFS file system based system and its zones are

upgraded with the following steps:

• The new boot environment is created and configured

• Patches are applied to the new, still inactive boot environment

• The new boot environment is activated

• The system is rebooted

Creating and Configuring the new Boot environmentThe lucreate command, used to create the new, inactive boot environment, has

a single mandatory command line option -n, to name the boot environment. In

addition, the lucreate command supports several command line options, including

an option to create the new boot environment based on the currently active boot

environment or based on another, previously created boot environment. The user

can also specify separate file systems belonging to a particular zone inside of the

new boot environment, and to create the file systems for a boot environment, but

leave those file systems unpopulated.

In the following example, the lucreate command is used to create the new boot

environment named new_be from the currently active boot:

s10u6# lucreate -n new_be

Note: When lucreate is invoked for the first time in a given instance of the Solaris OS environment, the system generates a default name that is used to save the currently active boot environment. Alternatively, the -c command line option can be used to assign a user-defined name for the active boot environment.

As the lucreate command runs, it reports on the various stages of creating

and populating the new boot environment. See section “Output of the lucreate

Command” on page 30 in the “Appendix” for a full listing of the output of the

lucreate command.

applying Patches to the new Boot environmentThe luupgrade command is used to install software on an inactive boot

environment, after it is created by the lucreate command. The luupgrade

command performs the following functions:

• Upgrade the operating system image on the inactive boot environment

• Add or remove packages or patches to or from the inactive boot environment

Note: A full operating system upgrade will not be discussed in this Sun BluePrints article.



.

The luupgrade command does not require the version of the Solaris OS it is running

on to be identical to that of the Solaris OS it is installing on the boot environment.

However, this capability is subject to several limitations, as described in the

luupgrade(1M) manual page. The lustatus command is used to check the status

of a boot environment, after luupgrade has completed.

The following example demonstrates the use of luupgrade to install patch

139503-01 on an inactive boot environment called new_be, without disrupting

the existing environment. The patch is automatically installed in the global and

local zones of new_be. The directory containing the patch is specified with the -s

command line option. The -s option can be used to point to a patch order file, or to

a directory with patches, packages, or a Solaris OS image:

s10u6# luupgrade -t -n new_be -s /var/tmp/139503-01

As the luupgrade command runs, it reports on its actions:

• Validate the patch

• Add the patch to new_be

• Report which patches are accepted or rejected for installation on new_be

• Patch the zones in new_be

• Report on success or failure

See section “Output of the luupgrade Command” on page 30 in the “Appendix” for a

full listing of the output of the luupgrade command in this example.

activating the new Boot environmentThe luactivate command is used to activate new_be:

s10u6# luactivate new_be

The luactivate command activates new_be, by making its root partition bootable.

It then displays a lengthy message with a warning to the user to only use the init

or shutdown commands to reboot and recovery instructions in case the system fails

to boot with new_be. For a full listing of the output of the luactivate command,

see section “Output of the luactivate Command” on page 32 in the “Appendix”.

For successful activation:

• new_be cannot have mounted partitions

• The lustatus command must report new_be as complete

• new_be cannot be involved in a comparison with the lucompare(1M) command

While running the luactivate command defines the new boot environment as the

active boot environment, it will only become the running boot environment after

.



.

a system reboot. In the interim, due to routine system administration actions, the

previously active boot environment might diverge from the newly activated boot

environment. To minimize the extent of this divergence it is recommended that the

system be rebooted as quickly as possible. Also, actions that would cause the new

boot environment to diverge from the currently running boot environment should be

avoided. To reboot, one of either the init or shutdown commands must be used,

since the activation of the new boot environment is completed as part of an orderly

shutdown.

Note: For the duration of the reboot the users experience downtime. However, a reboot can be expected to take a relatively short time and can be scheduled for a time that minimizes disruption.

Methods for Patching and Upgrading Solaris Cluster nodesSolaris Cluster environments are by nature mission-critical, with higher reliability

and resilience requirements compared to typical noncluster environments. There

are three different approaches to upgrading and patching a clustered environment.

These include standard upgrade, rolling upgrade, and dual-partition upgrade. To

minimize downtime and improve availability and reliability, each of the approaches

can be combined with Solaris Live Upgrade. In this section, an overview of these

approaches is provided.

Standard UpgradeA standard upgrade is performed as follows:

• All resource groups and resources are shut down and brought to the unmanaged

state

• The cluster is shut down

• The cluster nodes are rebooted into noncluster mode

• The upgrades are performed

• All of the nodes are rebooted into cluster mode

• The services are re-enabled

Without using Solaris Live Upgrade, this procedure requires relatively long cluster

downtime since it is executed while the applications are unavailable. However, if

a new boot environment is installed on each node using Solaris Live Upgrade and

activated, the only cluster downtime required is during a cluster reboot because the

upgrade itself is performed on the inactive boot environments. In addition, the risk

of unplanned downtime is reduced due to the fact that an upgrade failure can be

resolved by reactivating the previous boot environment and rebooting the cluster.



.

rolling UpgradeDuring a rolling upgrade, the cluster is always up and services are always available,

except for the duration of their switch between cluster nodes. The following steps

are performed on each node that is upgraded as part of a rolling upgrade:

• All of the services on the node to be upgraded are moved to other nodes

• The node is rebooted into noncluster mode

• The node is upgraded

• The upgraded node is rebooted into cluster mode and rejoins the cluster

Following the reboot of the first upgraded node and until all the nodes are upgraded,

the cluster runs different versions of the upgraded software on different nodes. This

state is only permitted to occur as an interim state for the purpose of the rolling

upgrade and while it is in progress.

While a cluster node is removed from the cluster to perform the upgrade, the cluster

runs with a lower level of redundancy. The duration of this higher-risk period can

be minimized by upgrading each node with Solaris Live Upgrade while the cluster is

running as normal. Once a node is upgraded, it can be rebooted and join the cluster

so that the cluster is back to its original level of redundancy. The time the cluster

runs with mixed software versions and at reduced redundancy can be minimized

by performing the reboot of several nodes simultaneously. As with the standard

upgrade, the risk of unplanned downtime is reduced since an upgrade failure can be

resolved by reactivating the previous boot environment and rebooting the cluster.

Note: A rolling upgrade is not possible with a major Solaris OS or Solaris Cluster upgrade.

Dual-Partition UpgradeWhere a rolling upgrade is not possible — for example, when executing a major

version upgrade for the Solaris OS or Solaris Cluster — the dual-partition upgrade

method can be used. In this method, the cluster is split into two sets of nodes called

partitions. The Solaris Cluster software helps to decide how to layout the partitions

by proposing a partition layout during the initiation of a dual-partition upgrade,

where all services can run in any partition and have access to that partition’s

storage. Once the old partition takes over the HA services and the other partition is

booted into noncluster mode, the other partition can be upgraded or patched.

During the reboot of the now upgraded or patched cluster partition, the Solaris

Cluster software synchronizes with the old and still active partition and performs the

following actions:

• Stop the services still running in the old partition

• Detach the active storage controlled by cluster resources from the old partition



.

• Shut down the old partition

• Attach the storage previously detached to the new partition

• Continue to boot the upgraded partition into cluster mode

• Start the HA services in the new partition

At this point, the old partition should be upgraded and rebooted into cluster mode.

Solaris Live Upgrade can be used to speed up the upgrade process, with the

partitioning and reboot occurring only after each node has had an updated boot

environment installed and activated. As with the other upgrade methods, the risk

of unplanned downtime is reduced since an upgrade failure can be resolved by

reactivating the previous boot environment and rebooting the cluster.

Note: One way that the dual-partition upgrade differs from a rolling upgrade is that the cluster is down at one point in time, but the new version of it is available shortly after. The length of time that users experience a service disruption with rolling and dual-partition upgrades is similar.



.

2. Moving the zone can be achieved either by restarting the zone on the new platform when the new platform has access to the storage that contains the zone’s file system — i.e., its zonepath — or by first copying the zone’s file system from the original platform to the new platform and restarting the zone.

Chapter 3

Using Solaris Update on attach

Solaris Zones allow each application to run in a self-contained, isolated, movable

environment. Solaris Zones provide applications with the security and reliability

of a dedicated server for each application, without the need to provide this server

with its own hardware platform. In addition, moving an application to a different

hardware platform with the same architecture becomes a simple exercise in shutting

down the application and its zone on one platform, and restarting them on the other

platform2.

Each instance of the Solaris OS consists of a single global zone that controls the

hardware resources, and any number of local zones that use the global zone to

access these resources. When a local zone is moved between systems, the global

zone on the destination system might not have the same packages and patch

levels as the global zone on the source system. As a result, once the local zone is

moved, it must be updated to match the destination system’s global zone. If many

local zones are deployed on a system, updating them when they are moved using

traditional tools requires a significant effort. Once initiated by the user, this process

can be automated with the update on attach feature, which examines a local zone

as it is moved to a new platform. The update on attach feature then determines the

packages that need to be upgraded to match the global zone that controls the new

platform, and executes the upgrade.

Note: It is essential that the latest applicable patches are installed on the target systems prior to running any of the examples described.

Commands overviewUpdate on attach is a feature of Solaris Zones that is controlled by several

subcommands of the zoneadm and zonecfg commands. These commands are listed

in Table 2.

Table 2. Solaris Zone commands relevant to update on attach

command Sub-

command

Functionality

zoneadm list Display name and details of zones

detach Detach the specified zone, as the first step in moving it from one

system to another

attach Attach a previously detached zone

zonecfg create Create an in-memory configuration for the specified zone



.

Executing the various tasks associated with upgrade on attach is simplified by

certain features of the ZFS file system, most notably by its snapshot capability, which

facilitates a quick rollback. The ZFS file system commands used in the upgrade on

attach examples are listed in Table 3.

Table 3. ZFS file system commands relevant to update on attach

command Sub-

command

Functionality

zfs snapshot Create a snapshot.

list List the property information of the ZFS file system data sets and

snapshots.

rollback Roll back a data set to its previous snapshot.

zpool export Export ZFS file system pools from the system. The devices are

marked as exported, but are still considered in use by other

subsystems.

import List or import ZFS file system pools.

Solaris Cluster resources and resource groups are managed by the clrs and clrg

commands respectively. The Solaris Cluster commands used in the upgrade on attach

in a Solaris Cluster environment example are listed in Table 4.

Table 4. Solaris Cluster commands to manage resources that are relevant to update on attach

command Sub-

command

Functionality

clrg switch Changes the node or zone that is mastering a resource group

status Generates a status report for resource groups

offline Takes a resource group offline

online Brings a resource group online

clrs disable Disables the specified resources

enable Enables the specified resources

status Generates a status report for the specified resources

Update on attach examplesTwo examples of using the update on attach feature are described:

• Moving local zones (zone1 and zone2) that share storage from one system

( oldhost) to another system (newhost), resulting in the automatic upgrade

of the local zones to the patch and package level of newhost’s global zone.

Subsequently, the zones are rebooted. The update is then reversed by using a

snapshot of oldhost, and the zones are returned to oldhost.



.

3. For Solaris 10 5/09 or later, The IDR patches can be removed automatically by using the -b option to zoneadm when attaching the local zone in step 8 below.

• Update on attach on a failover zone tzone on a two node cluster comprised of

node1 and node2 controlled by Solaris Cluster 3.2 1/09 software. tzone’s zonepath

is on a ZFS file system on shared storage. tzone is moved off of node1, the global

zone on node1 is upgraded, tzone is moved back to node1, and upgraded to the

patch and package level of the global zone on node1.

limitations of the Update on attach FeatureUpdate on attach is relevant only to Solaris Zones and not to other virtualization

technologies. In addition, it is subject to the following limitations and prerequisites:

• The systems must run Solaris 10 10/08 (Update 6), which is the first version of the

Solaris OS to support the update on attach feature, or later.

• When running the update on attach feature on a local zone, it only updates

packages that are required to be consistent in all zones.

• Neither the source nor target operating environments can include patches classed

as Interim Diagnostic Relief (IDR) patches. When IDR patches are present in the

source operating environment, they must be removed before upgrading the

system3.

• Update on attach does not update application software.

• The patch level of each package and patch on newhost is equal to or higher than

its equivalent on oldhost.

For further details of these and other limitations please see the article “The Zones

Update on Attach Feature and Patching in the Solaris 10 OS”, through the link to it in

“References” on page 28.

Moving the local ZonesMoving the local zones consists of the following steps, described in the sections to

follow:

• Shutting down the local zones and detaching them, saving their state using a ZFS

file system snapshot, and exporting the zpool containing their zonepaths.

• Importing the zpool containing the zonepaths to the destination host and

attaching it while running the update on attach feature.

• Rolling back the zones to their previous state if the update on attach feature fails

to successfully update them.

Shutting Down and exporting the local ZonesThe process of exporting the zones consists of the following steps:

1. Run the zoneadm list command to display all of the zones that are currently

installed on oldhost. The -v command line option enables verbose output,



.

and -i and -c display all of the installed and configured zones. In this

instance, there are two local zones — zone1 and zone2 — with the zonepaths

/shared-zones/zone1 and /shared-zones/zone2 respectively:

oldhost# zoneadm list -vic

ID NAME STATUS PATH BRAND IP

0 global running / native shared

3 zone1 running /shared-zones/zone1 native shared

4 zone2 running /shared-zones/zone2 native shared

2. Shut down the local zones:

oldhost# zlogin zone1 shutdown -i 0oldhost# zlogin zone2 shutdown -i 0

Each invocation of the shutdown command runs the shutdown scripts inside

the zone, removes the zone’s runtime resources, and halts it.

3. When the state of the zone changes from running to installed, as shown by

the zoneadm list command, the zones have been halted and can be detached:

oldhost# zoneadm -z zone1 detacholdhost# zoneadm -z zone2 detach

The zoneadm detach command saves the zones’ package and patch state

information into single files. These files are used to reattach the zones using the

zoneadm attach command, once each of the zones is moved.

4. Generate a read-only snapshot of the shared-zones zpool, called

shared-zones@downrev. This snapshot retains the complete state of the zones’

file systems:

oldhost# zfs snapshot -r shared-zones@downrev

5. List the volumes currently known by the ZFS file system on oldhost. Note the

presence of the shared-zones@downrev snapshot that is not mounted, in

addition to the shared-zones file system:

oldhost# zfs list

NAME USED AVAIL REFER MOUNTPOINT

...

shared-zones 4.18G 15.4G 4.14G /shared-zones

shared-zones@downrev 46.3M - 4.13G -

6. Export the pool to prepare it to be moved:

oldhost# zpool export shared-zones



.

Note: A ZFS file system pool cannot be exported if it has a spare device that is shared with other pools and is currently used.

7. List the zones on oldhost. Only the global zone should be running:




- zone1 configured /shared-zones/zone1 native shared


Before moving a local zone, the patch levels of the packages the local zone contains

should be compared with the global zone running on the local zone’s host, to check

that they are identical. This should be done as part of regular system maintenance to

identify inconsistencies introduced in error. The patch levels of the global and local

zones can be compared by examining the list of packages and patches for each zone

generated with the pkginfo and showrev -p commands. Alternatively, Sun xVM

Ops Center can be used to automate this process.

Note: Only the packages that are installed on the global zone on newhost and that have the SUNW_PKG_ALL_ZONES flag set to true are updated. The SUNW_PKG_ALL_ZONES flag indicates that these packages must be consistent across all zones, or are in a package directory inherited by the zone. The rest of the packages can diverge and remain untouched.

Given that oldhost and newhost share storage, once the zones are halted and

detached from oldhost and the snapshots prepared, the zpools containing their

zonepaths can be exported from oldhost, imported, and reattached to newhost.

importing the local ZonesOnce the zones are exported on oldhost and the zpool is available to newhost, the

zones can be attached and activated on newhost with the following steps:

1. Run the zpool import command without any parameters to see what pools

are available for import:

newhost# zpool importpool: shared-zones id: 9978900745171968029state: ONLINEaction: action: The pool can be imported using its name or numeric identifier.config:shared-zones ONLINEc0d1 ONLINE



.

2. Run the zpool import command with the pool name to execute the import:

newhost# zpool import shared-zones

3. Run the zoneadm list command to determine what zones are running on this

system. Only the global zone should be listed:

newhost# zoneadm list -vic



4. Run the zfs list command to check that the file systems that are part of the

shared-zones zpool, are mounted:

newhost# zfs list


...



5. If the file systems are not mounted, run the zfs mount command to

mount them. This can take one of two forms, depending on the value of the

mountpoint property set by the zfs set command. If the mountpoint

property was set to a specific path, run the following command:

newhost# zfs mount shared-zones

If the mountpoint property was set to legacy, run the following command:

newhost# mount -F zfs shared-zones /shared-zones

6. Create the new configured zones with the zonecfg create command. Use the

-z option to specify the name of the zone, and -a to define the path for the

detached zone that was moved to newhost:

newhost# zonecfg -z zone1 create -a /shared-zones/zone1newhost# zonecfg -z zone2 create -a /shared-zones/zone2

Note: The silent success of the zonecfg command does not indicate that the transfer of the zone was successful, since the zone is validated when it is attached, not when it is configured.



.

7. Run the zoneadm attach command, without invoking the update on attach

feature, to try to attach zone1 to newhost. In this example, oldhost has a single

package — SUNWstosreg — that has not been installed on newhost, and two

patches — 119963 and 120812 — that are not at the same revision level on both

hosts. These discrepancies cause the zoneadm attach command to fail:

newhost# zoneadm -z zone1 attachThese packages installed on the source system are inconsistent with this system: SUNWstosreg: not installed(1.0,REV=2007.05.21.20.36)These patches installed on the source system are inconsistent with this system: 119963: version mismatch(10) (11)120812: version mismatch(25) (27)

8. Run the zoneadm attach command again to attach zone2 to newhost. This

time invoke the update on attach feature by specifying the -u command line

option:

newhost# zoneadm -z zone2 attach -uGetting the list of files to removeRemoving 15 filesRemove 2 of 2 packagesInstalling 31 filesAdd 2 of 2 packagesUpdating editable filesThe file </var/sadm/system/logs/update_log> within the zone contains a log of the zone update.

The superfluous packages are removed and the missing packages are installed

to make zone2 compatible with the package and patch state of the global zone

on newhost.

Note: The time required for the update on attach feature to complete the software upgrade depends on the number of packages and patches that need to be updated. An invocation of the update on attach feature with only a few patches should normally take a short period of time — probably no more than a few minutes. However, complex operating system upgrades can take much longer.



.

4. Saving ZFS filesystem snapshots prior to executing a procedure that can potentially damage local zones to help enable their roll-back to a prior state is a recommended precaution to help minimize unplanned disruption.

rolling Back the Updated local ZonesWhen update on attach fails and the local zones are damaged, the local zones must

be restored to their original state using the snapshot that was saved earlier4 (see

“Shutting Down and Exporting the Local Zones” on page 12). The zpools with the

zonepaths must be exported from oldhost first:

1. Check that the snapshot exists on oldhost and that both zones are configured

with the zoneadm list command:






2. Run the zpool import command with no parameters to see whether the zpool

is available for import:

oldhost# zpool importpool: shared-zones id: 9978900745171968029state: ONLINEaction: The pool can be imported using its name or numeric identifier.config:shared-zones ONLINEc0d1 ONLINE

3. Run the zpool import command using the zpool name:

oldhost# zpool import shared-zones

4. Run a zfs list command to check that the snapshot is available on oldhost:

oldhost# zfs list


...





.

5. Try to attach zone1 to oldhost using the zoneadm attach command. The

command fails because upgrades that were applied by the update on attach

feature to zone1 when it was attached to newhost prevent the reattachment of

zone1 to oldhost:

oldhost# zoneadm -z zone1 attachThese packages installed on this system were not installed on the source system:SUNWstosreg (1.0,REV=2007.05.21.20.36)These patches installed on the source system are inconsistent with this system:119963: version mismatch(11) (10)120812: version mismatch(27) (25)

6. Run the zfs rollback command on the saved snapshot to revert it to its

previous state and make it possible to reattach both local zones to oldhost:

oldhost# zfs rollback shared-zones@downrev oldhost# zoneadm -z zone1 attach oldhost# zoneadm -z zone2 attach

Update on attach in a Solaris Cluster environmentIn the past, mission-critical applications would be deployed on independent cluster

environments and there were no dependencies between the different clusters

running the different applications. Today, as part of the growing need for more

efficient application deployment, several mission-critical applications can be

consolidated onto a single Solaris Cluster platform using Solaris Zones. This trend

produces cluster deployments with many applications and failover zones.

By their nature, cluster environments require higher availability than nonclustered

environments at both the application and infrastructure levels. This need implies

that planned system and application downtime must be kept to the bare minimum,

making it difficult to schedule planned downtime. When a cluster is shared by

multiple applications this scheduling difficulty is further exacerbated by the need

to coordinate planned downtime with multiple application owners. Conversely,

when using the update on attach feature, a separate downtime can be set for each

application and zone.

the Sample ConfigurationIn this example, the cluster to be patched consists of two nodes — node1 and node2.

The Solaris OS version is Solaris 10 Update 5 with patches. The local zone, tzone,

is controlled by the cluster, tzone is part of the resource group (RG) tzone-rg, and



.

tzone’s zonepath is configured on shared storage in a ZFS file system mounted on

/zones/tzone, as verified by running the zoneadm list command:

node1# zoneadm list -icv



3 tzone running /zones/tzone native shared

Note: This example was tested using Solaris Cluster 3.2 1/09. Using update on attach to install Solaris Cluster patches is currently not supported.

Failover ZonesIn a Solaris Cluster deployment with multiple applications, the applications can be

switched from a node to be patched to another node in the cluster, freeing the first

node to be patched or upgraded without the users experiencing any application

downtime. In such a configuration, a rolling upgrade can provide optimal application

availability. However, with failover zones all zones installed on a given node must

be patched simultaneously with the global zone. As a result, the downtime must be

coordinated with all of the owners of applications running in failover zones. A rolling

upgrade using update on attach can be used to circumvent this issue.

A failover zone is usually used to allow application owners to control their

application’s operating environment, and they must manage their application within

the zone. The failover zone is separately managed and monitored from the global

zone. By attaching the shared storage with the failover zone’s zonepath to another

cluster node, the other node can boot the failover zone and provide the service.

In a Solaris Cluster environment failover zones are configured using the HA Container

agent. The HA Container agent integrates a failover zone into the Solaris Cluster

environment by providing the means to start, stop, and monitor the zone. When

a node with a failover zone fails, the failover zone is switched to another node. A

Solaris Cluster failover zone is configured as a resource group. This resource group

typically contains three resources:

• A storage resource of type HAStoragePlus, which controls the shared storage

that hosts the failover zone’s file systems

• A logical IP address resource of type LogicalHostname that is used to access the

failover zone

• The zone resource itself of the generic data service type (gds) used for the HA

container agent, which is dependent on the storage and logical IP resources

Note: The dependency between the zone resource and the IP address and storage resources means that the zone resource can only be started if the IP address and storage resources are available.



.

Update Procedure overviewThe following steps provide an overview of the update on attach process for failover

zones. These steps are described in detail in the following sections:

1. Move all of the local zones to be updated with update on attach from node1 to

node2 using cluster commands.

2. Upgrade the global zone on node1.

3. Reboot node1 to rejoin the cluster. The cluster now runs nodes with different

patch or package versions or different Solaris OS minor releases. This

intermediate state is not recommended for production systems and should only

be allowed for as short a time as possible — while the upgrade is in progress.

4. For each failover zone on node2, remove the zone resource from the cluster

software’s control, move the zonepath to node1 using cluster commands, attach

the zone to node1, and upgrade it with the update on attach feature. To speed

up the process, this can be performed in parallel for multiple zones. While the

zones are updated, only the applications running in each zone suffer downtime.

5. Boot the zone once, then shut it down and instruct the cluster to regain control

of it.

6. Upgrade node2.

Note: In the interests of simplicity, the steps to create ZFS snapshots to help enable roll-back if the update procedure described here fails are omitted from the description. See the section “Moving the Local Zones” on page 12 for an example of using ZFS snapshots for this purpose.

Upgrading the First Cluster nodeTo upgrade node1, the resource group controlling tzone is switched to node2. node1

is then rebooted in noncluster mode and upgraded using one of the described

procedures. This means that tzone is active on node2 and provides all of its services,

while node1 can be upgraded without affecting the applications’ availability. Before

starting this procedure, make sure that no LUN containing an affected zonepath is

configured as a quorum device:

1. List the names of the Solaris Cluster resources with the clrs command to

ascertain that this prerequisite is met:

node1# clrs list -v -g tzone-rg

Resource Name Resource Type Resource Group

------------- ------------- --------------

tzone-ip SUNW.LogicalHostname:2 tzone-rg

tzone-hasp SUNW.HAStoragePlus:6 tzone-rg

tzone-rs SUNW.gds:6 tzone-rg



.

2. The clrg command manages Solaris Cluster data service resource groups. The

clrg switch command changes the specified node or zone that is mastering

a resource group. Run the clrg switch command to move resource group

tzone-rg to node2:

node1# clrg switch -n node2 tzone-rg

3. After the upgrade the global zone on node1 will run with a newer patch-level

than local zone tzone, so if tzone is switched to node1 it could fail. To avoid

this risk, prevent tzone from switching to node1 by setting tzone’s Nodelist

property as defined in the tzone-rg resource group to include only the nodes

that have not been upgraded yet:

node2# clrg set -p Nodelist=node2 tzone-rg

Note: The time the cluster is allowed to remain in this state should be minimized, since while tzone cannot be switched to node1, tzone has an increased risk of failure due to the reduced node count.

4. Run the zoneadm detach command to change tzone’s state from installed

to configured, so that the subsequent update procedure on node1 does not

attempt to update tzone. Use zoneadm list to verify that tzone’s state has in

fact changed:

node1# zoneadm -z tzone detachnode1# zoneadm -z tzone list -v


- tzone configured /zones/tzone native shared

Note: The zonepath itself has already been switched to the other node in step 2, above.

5. The detach operation creates the file /zones/tzone/SUNWdetached.xml in

tzone’s now empty zonepath on node1. This file contains package and patch

information about the detached zone. As the zone has already been switched,

its contents are not needed. However, the existence of this file would interfere

with the attach process. Remove it with the following command:

node1# rm -f /zones/tzone/SUNWdetached.xml

6. Reboot node1 in noncluster mode by using the -x option so that the global zone

can be upgraded:

node1# reboot -x

7. Upgrade node1’s global zone and allow node1 to rejoin the cluster.



.

running the Update on attach FeatureThe following steps move tzone’s zonepath to node1 and run the update on attach

feature to upgrade tzone to the level of the global zone on node1:

8. Recall that node1 was removed from the list of nodes that can master tzone by

removing it from the tzone Nodelist property in the tzone-rg resource group.

Now return it, since the resource group is going to be switched over to node1:

node2# clrg set -p Nodelist=node1,node2 tzone-rg

9. To prevent the zone from booting when the resource group is switched over, the

zone resource is disabled, shutting down tzone without detaching it. To switch

over the zonepath using a cluster command its HAStoragePlus resource must

remain online together with its logical IP address, because there is an implicit

dependency on the logical IP address. Check the status of the resource group

and then disable the zone resource:

node2# clrg status tzone-rg=== Cluster Resource Groups ===

Group Name Node Name Suspended Status

---------- --------- --------- ------

tzone-rg node2 No Online

node1 No Offlinenode2# clrs disable tzone-rs

The IP address and the zonepath are still active while the local zone itself is

disabled.

10. Detach tzone to change its state to configured so that the subsequent update

procedure on node2 does not attempt to update tzone:

node2# zoneadm -z tzone detach

12. The zoneadm attach -u command, when invoked in step 14, initially

looks for the /zones/tzone/SUNWdetached.xml file that contains the

package and patch status of the zone. If one is found, the real package

and patch status of the zone to be attached is not considered. While

normally the real package and patch status of the zone and its reflection in

/zones/tzone/SUNWdetached.xml are identical, there are certain cases

where it is not. For this reason, the file is removed:

node2# rm -f /zones/tzone/SUNWdetached.xml



.

13. Run the clrg switch command to switch the tzone-rg resource group to node1

and import and mount the zpool containing the tzone’s zonepath:

node2# clrg switch -n node1 tzone-rg

Note: In production environments with many failover zones, several zones can be moved and updated simultaneously to expedite the upgrade process.

14. Attach tzone to node1 using the -u option of the zoneadm attach command

to run the update on attach feature. In the invocation shown here, running the

update on attach feature fails since node1 contains a package with an earlier

revision than that of tzone and the update on attach feature is not able to

downgrade packages:

node1# zoneadm -z tzone attach -uzoneadm: zone ‘node1-template’: ERROR:attempt to downgrade package SUNWdmcon 3.0.2,REV=2006.12.11.14.47.33 to version 3.0.2,REV=2006.10.13.15.53.40

15. After upgrading the appropriate package, successfully run the update on attach

feature:

node1# zoneadm -z tzone attach -uGetting the list of files to removeRemoving 1115 filesRemove 785 of 785 packagesInstalling 1455 filesAdd 664 of 664 packagesUpdating editable filesThe file </var/sadm/system/logs/update_log> within the zone contains a log of the zone update.

Bringing the Failover Zone Back Under Cluster ControlAt this stage, the failover zone is up to date and can be brought back into the cluster:

16. Boot tzone manually and verify that it booted successfully by logging into its

console:

node1# zoneadm -z tzone bootnode1# zlogin -C tzonetzone# ^Dnode1#

Note: The first time tzone is booted it must be booted manually and not by the cluster software. This is because automatic administrative procedures that might be triggered during this first boot process can create a significant delay in its completion. This delay can be misinterpreted by the Solaris Cluster software as a failure of tzone.



.

17. Stop tzone:

node1# zlogin tzone shutdown -i 0

18. Check tzone’s status:

node1# clrs status -g tzone-rg=== Cluster Resources ===

Resource Name Node Name State Status Message

------------ -------- ----- -------------

tzone-ip node2 Offline Offline - LogicalHostname offline.

node1 Online Online - LogicalHostname online.

tzone-hasp node2 Offline Offline

node1 Online Online

tzone-rs node2 Offline Offline

node1 Offline Offline

The output of the clrs status command shows that the resources tzone-ip

and tzone-hasp, which represent the logical IP address and storage resources,

are still online. The tzone-rs resource, which represents the failover zone

itself, is still offline.

19. At this point, tzone and node1 have both been upgraded, while node2 has not.

Thus, tzone and node2 are running different software versions and tzone should

not be permitted to fail over to node2. To prevent tzone from failing over to

node2, node2 is removed from the list of nodes that can host tzone by changing

the Nodelist property in the tzone’s group to include only node1:

node1# clrg set -p Nodelist=node1 tzone-rg

20. Enable tzone so that it will boot under cluster control:

node1# clrs enable tzone-rs

21. Check that tzone’s status is running:

node1# zoneadm -z tzone list -v


3 tzone running /zones/tzone native shared



.

Upgrading the Second nodeOnce all of the failover zones are upgraded by moving them from node2 to node1,

and the update on attach feature is invoked, node2 can be upgraded using the same

method that was used for node1.

22. Before upgrading node2, verify that the status of tzone on node2 is configured

and not installed:

node2# zoneadm -z tzone list -v


- tzone configured /zones/tzone native shared

23. Upgrade node2 as required.

24. Attach tzone to node2 using the -F option to force the operation. Following

the upgrade of node2, tzone’s state remains configured on node2. Running

the zoneadm attach command with the -F option changes the status to

installed. While normally using -F is dangerous and not recommended, in

this case it is permissible since tzone has just been upgraded correctly:

node2# zoneadm -z tzone attach -Fnode2# zoneadm -z tzone list -v


- tzone installed /zones/tzone native shared

Note: Normally, the attach command compares the state of the global zone and the local zone to be attached. However, it can be safely assumed that the process that has just been executed makes this comparison unnecessary. If the zone is disabled, switching its zonepath and re-attaching it would entail further non-essential service interruptions to the services on the zone. Running attach -F simply changes the zone’s state to installed, which is sufficient for the Solaris Cluster HA Container agent to work without disabling the zone.

25. After upgrading all of the nodes revert the nodelist property of tzone back

to include both node1 and node2 to restore the cluster to its fully redundant

configuration:

node1# clrg set -p Nodelist=node1,node2 tzone-rg

Now the failover zone is under full cluster control and can be automatically or

manually switched between the nodes in the event of a failover.



.

Preventing upgrade failures in production systemsThe procedure to upgrade a cluster described here results in a short service

interruption while the failover zones are switched, and while the update on attach is

in progress. In addition, temporarily removing the nodes from the cluster while the

upgrade is in progress creates an increased risk of failure due to reduced redundancy.

If the upgrade fails, the risk is increased further since the cluster must function with

fewer nodes for a longer period of time.

To minimize this risk, the upgrade should first be tested on a separate test system

using a snapshot of the current operating environment, and updated with the

update on attach feature. Any failure in this test procedure identifies and helps

resolve the issues that might result in a failure of the upgrade.

The period of reduced redundancy can be shortened by using Live Upgrade to

upgrade the individual nodes, since each node is fully functional while it is being

upgraded, and is removed from the cluster only while it is rebooted.



.

Chapter 4

Conclusion

Virtualization technologies such as Solaris Zones create immense opportunity

for a more cost-effective, efficient, flexible, and reliable datacenter environment,

at the cost of increased complexity and some application interdependency. The

maintenance requirements of the ever-increasing number of virtual operating system

environments create challenges at both the technical and administration levels.

At the technical level, the systems must be upgraded to help ensure stability and

functionality. At the administrative level, the large number of stakeholders of the

interdependent applications create serious challenges in planning and coordinating

agreed maintenance downtime.

The maintenance technologies described in this Sun BluePrints article remove many

of the interdependencies between applications and reduce the extent of the planned

downtime required for maintaining operating environments. These technologies

reduce the datacenter maintenance challenges and risks while increasing the ability

to meet the businesses users’ service level requirements.

about the authorsThis Sun BluePrints article was authored by a team of specialists from the Sun

Microsystems systems practice in Germany:

• Martin Müller has been working as an IT architect and datacenter ambassador for

Sun Microsystems for the past 12 years. He is a specialist in Sun’s SPARC® systems

and the Solaris Operating System.

• Hartmut Streppel has been working as a principal field technologist and

datacenter ambassador for Sun Microsystems for the past 10 years. He is an

acknowledged worldwide expert in the field of high availability, business

continuity, and Solaris Cluster software.

• Dirk Augustin has been working for Sun Microsystems as an SAP solution and

datacenter architect for the past 9 years. He is a certified SAP consultant.

acknowledgmentsThe authors would like to recognize Ralf Zenses, Lajos Hodi, and Detlef Drewanz for

their technical advice.



.

references

Table 5. References for more information

web Sites

BigAdmin, System Administrator

Resources and Community

http://sun.com/bigadmin/

Solaris 10 5/09 Release and Installation

Collection

http://docs.sun.com/app/docs/coll/1236.10/

Solaris 10 5/09 Installation Guide: Solaris

Live Upgrade and Upgrade Planning

http://docs.sun.com/app/docs/doc/820-7013/

Sun Cluster Upgrade Guide for Solaris OS

(for Sun Cluster 3.2 1/09)


Sun xVM Ops Center 2.0 Wiki http://wikis.sun.com/display/xvmOC2dot0/

Home/

Sun’s ZFS Learning Center http://sun.com/software/solaris/

zfs_learning_center.jsp

OpenSolaris Community: ZFS http://opensolaris.org/os/community/zfs/

Sun xVM Ops Center http://sun.com/software/products/

xvmopscenter/

System Administration Guide: Solaris

Containers-Resource Management and

Solaris Zones


How to Upgrade the Solaris OS and Sun

Cluster 3.2 1/09 Software (Live Upgrade)


chapupgrade-5478/

The Zones Update on Attach Feature and

Patching in the Solaris 10 OS

http://sun.com/bigadmin/features/articles/

zone_attach_patch.jsp

Non-Global Zone State Model http://docs.sun.com/app/docs/doc/817-1592/

zones.intro-12/

Performing a Live Upgrade to Sun Cluster

3.2 1/09 Software


gcssh/

Sun Blueprints articles

Best Practices For Running Oracle

Databases in Solaris Containers

http://wikis.sun.com/display/BluePrints/

Best+Practices+for+Running+Oracle+

Databases+in+Solaris+Containers

other articles

Minimizing Downtime In SAP

Environments

http://sun.com/third-party/global/sap/

collateral/Minimizing_Downtime_of_SAP_

Environments_WP.pdf


http://sun.com/bigadmin/

http://docs.sun.com/app/docs/coll/1236.10/


http://docs.sun.com/app/docs/doc/820-4678

http://wikis.sun.com/display/xvmOC2dot0/Home

http://wikis.sun.com/display/xvmOC2dot0/Home

http://www.sun.com/software/solaris/zfs_learning_center.jsp

http://www.sun.com/software/solaris/zfs_learning_center.jsp

http://opensolaris.org/os/community/zfs/

http://sun.com/software/products/xvmopscenter

http://sun.com/software/products/xvmopscenter

http://docs.sun.com/app/docs/doc/817-1592

http://docs.sun.com/app/docs/doc/820-4678/chapupgrade-5478?l=en&a=view

http://docs.sun.com/app/docs/doc/820-4678/chapupgrade-5478?l=en&a=view

http://sun.com/bigadmin/features/articles/zone_attach_patch.jsp

http://sun.com/bigadmin/features/articles/zone_attach_patch.jsp

http://docs.sun.com/app/docs/doc/817-1592/zones.intro-12

http://docs.sun.com/app/docs/doc/817-1592/zones.intro-12

http://docs.sun.com/app/docs/doc/820-4678/gcssh

http://docs.sun.com/app/docs/doc/820-4678/gcssh

http://wikis.sun.com/display/BluePrints/ Best+Practices+for+Running+Oracle+ Databases+in+Solaris+Containers



http://www.sun.com/third-party/global/sap/collateral/Minimizing_Downtime_of_SAP_Environments_WP.pdf




.

ordering Sun DocumentsThe SunDocsSM program provides more than 250 manuals from Sun Microsystems,

Inc. If you live in the United States, Canada, Europe, or Japan, you can purchase

documentation sets or individual manuals through this program.

accessing Sun Documentation onlineThe docs.sun.com Web site enables you to access Sun technical documentation

online. You can browse the docs.sun.com archive or search for a specific book title or

subject. The URL is http://docs.sun.com.

To reference Sun BluePrints article Online articles, visit the Sun BluePrints Online

Web site at: http://sun.com/blueprints/online.html.


http://www.sun.com/blueprints/online.html


.

Chapter 5

appendix

output of the lucreate Commands10u6# lucreate -n new_beAnalyzing system configuration.Comparing source boot environment <old_be> file systems with the file system(s) you specified for the new boot environment. Determining which file systems should be in the new boot environment.Updating boot environment description database on all BEs.Updating system configuration files.Creating configuration for boot environment <new_be>.Source boot environment is <old_be>.Creating boot environment <new_be>.Cloning file systems from boot environment <old_be> to create boot environment <new_be>.Creating snapshot for <rpool/ROOT/old_be> on <rpool/ROOT/old_be@new_be>.Creating clone for <rpool/ROOT/old_be@new_be> on <rpool/ROOT/new_be>.Setting canmount=noauto for </> in zone <global> on <rpool/ROOT/new_be>.Creating snapshot for <rpool/zones/sparse> on <rpool/zones/sparse@new_be>.Creating clone for <rpool/zones/sparse@new_be> on <rpool/zones/sparse-new_be>.Creating snapshot for <rpool/zones/whole> on <rpool/zones/whole@new_be>.Creating clone for <rpool/zones/whole@new_be> on <rpool/zones/whole-new_be>.Population of boot environment <new_be> successful.Creation of boot environment <new_be> successful.

output of the luupgrade Commands10u6# luupgrade -t -n new_be -s /var/tmp/1139503-01

Validating the contents of the media </var/tmp>.

The media contains 1 software patches that can be added.

Mounting the boot environment <new_be>.

Adding patches to the boot environment <new_be>.

Validating patches...

Loading patches installed on the system...

Done!

Loading patches requested to install.

Done!



.

Checking patches that you specified for installation.

Done!

Approved patches will be installed in this order:

139503-01

Preparing checklist for non-global zone check...

Checking non-global zones...

This patch passes the non-global zone check.

139503-01

Summary for zones:

Zone sparse

Rejected patches:

None.

Patches that passed the dependency check:

139503-01

Zone whole

Rejected patches:

None.

Patches that passed the dependency check:

139503-01

Patching global zone

Adding patches...

Checking installed patches...

Verifying sufficient file system capacity (dry run method)...

Installing patch packages...

Patch 139503-01 has been successfully installed.

See /a/var/sadm/patch/139503-01/log for details

Patch packages installed:

SUNWckr

Done!

Patching non-global zones...

Patching zone sparse

Adding patches...







SUNWckr

Done!

Patching zone whole

Adding patches...



.







SUNWckr

Done!

Unmounting the boot environment <new_be>.

The patch add to the boot environment <new_be> completed.

output of the luactivate Commands10u6# luactivate new_beA Live Upgrade Sync operation will be performed on startup of boot environment <new_be>.*************************************************************The target boot environment has been activated. It will be used when you reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You MUST USE either the init or the shutdown command when you reboot. If you do not use either init or shutdown, the system will not boot using the target boot environment.*************************************************************In case of a failure while booting to the target boot environment, the following process needs to be followed to fallback to the currently working boot environment:1. Enter the PROM monitor (ok prompt).2. Boot the machine to Single User mode using a different boot device (like the Solaris Install CD or Network). Examples:At the PROM monitor (ok prompt):For boot to Solaris CD: boot cdrom -sFor boot to network: boot net -s3. Mount the Current boot environment root slice to some directory (like /mnt). You can use the following command to mount:mount -Fzfs /dev/dsk/c0d0s0 /mnt4. Run <luactivate> utility with out any arguments from the current boot environment root slice, as shown below:/mnt/sbin/luactivate5. luactivate, activates the previous working boot environment and indicates the result.6. Exit Single User mode and reboot the machine.*************************************************************Modifying boot archive serviceActivation of boot environment <new_be> successful

Note: This example is specific to SPARC systems with a PROM monitor, running the Solaris OS.


Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 USA Phone 1-650-960-1300 or 1-800-555-9SUN (9786) Web sun.com

© 2009 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems, the Sun logo, Sun BluePrints, Solaris, and ZFS, are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the US and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. Information subject to change without notice. Printed in USA 09/09

Sun Microsystems, Inc.Maintaining Solaris with Live Upgrade and Update On Attach

Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 USA Phone 1-650-960-1300 or 1-800-555-9SUN (9786) Web sun.com


Maintaining Solaris Systems with Solaris Live Upgrade and Update on Attach September 2009

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200

oracle.com

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd. 1010
