Moving the Local Zones

Moving 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 Zones

The process of exporting the zones consists of the following steps:
1. Run the zoneadmlistcommand to display all of the zones that are currently
installed on oldhost. The vcommand line option enables verbose output,
13 Maintaining Solaris with Live Upgrade and Update On Attach Sun Microsystems, Inc.

and iand cdisplay all of the installed and configured zones. In this
instance, there are two local zones
zone1 and zone2 with the zonepaths
/sharedzones/zone1and /sharedzones/zone2respectively:
oldhost#zoneadmlistvic

IDNAMESTATUSPATHBRANDIP
0globalrunning/nativeshared
3zone1running/sharedzones/zone1nativeshared
4zone2running/sharedzones/zone2nativeshared
2. Shut down the local zones:
oldhost#zloginzone1shutdowni0
oldhost#zloginzone2shutdowni0
Each invocation of the shutdowncommand runs the shutdown scripts inside

the zone, removes the zones runtime resources, and halts it.
3. When the state of the zone changes from runningto installed, as shown by
the zoneadmlistcommand, the zones have been halted and can be detached:
oldhost#zoneadmzzone1detach
oldhost#zoneadmzzone2detach
The zoneadmdetachcommand saves the zones package and patch state

information into single files. These files are used to reattach the zones using the
zoneadmattachcommand, 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#zfssnapshotrsharedzones@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#zfslist
NAMEUSEDAVAILREFERMOUNTPOINT
...
sharedzones4.18G15.4G4.14G/sharedzones
sharedzones@downrev46.3M4.13G

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

oldhost#zpoolexportsharedzones
14 Maintaining Solaris with Live Upgrade and Update On Attach Sun Microsystems, Inc.

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:
oldhost#zoneadmlistvic

IDNAMESTATUSPATHBRANDIP
0globalrunning/nativeshared
zone1configured/sharedzones/zone1nativeshared
zone2configured/sharedzones/zone2nativeshared

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 zones 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 pkginfoand showrevpcommands. 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_ZONESflag 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 Zones

Once 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 zpoolimportcommand without any parameters to see what pools
are available for import:
newhost#zpoolimport
pool:sharedzonesid:9978900745171968029
state:ONLINE
action:
action:Thepoolcanbeimportedusingitsnameornumeric
identifier.
config:
sharedzonesONLINE
c0d1ONLINE
15 Maintaining Solaris with Live Upgrade and Update On Attach Sun Microsystems, Inc.

2. Run the zpoolimportcommand with the pool name to execute the import:
newhost#zpoolimportsharedzones
3. Run the zoneadmlistcommand to determine what zones are running on this

system. Only the global zone should be listed:

newhost#zoneadmlistvic
IDNAMESTATUSPATHBRANDIP
0globalrunning/nativeshared
4. Run the zfslistcommand to check that the file systems that are part of the

shared-zones zpool, are mounted:

newhost#zfslist
NAMEUSEDAVAILREFERMOUNTPOINT
...
sharedzones4.18G15.4G4.14G/sharedzones
sharedzones@downrev46.3M4.13G
5. If the file systems are not mounted, run the zfsmountcommand to

mount them. This can take one of two forms, depending on the value of the
mountpointproperty set by the zfssetcommand. If the mountpoint
property was set to a specific path, run the following command:
newhost#zfsmountsharedzones
If the mountpointproperty was set to legacy, run the following command:
newhost#mountFzfssharedzones/sharedzones
6. Create the new configured zones with the zonecfgcreatecommand. Use the
zoption to specify the name of the zone, and ato define the path for the

detached zone that was moved to newhost:

newhost#zonecfgzzone1createa/sharedzones/zone1
newhost#zonecfgzzone2createa/sharedzones/zone2
Note: The silent success of the zonecfgcommand 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.
16 Maintaining Solaris with Live Upgrade and Update On Attach Sun Microsystems, Inc.

7. Run the zoneadmattachcommand, 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 zoneadmattachcommand to fail:
newhost#zoneadmzzone1attach
Thesepackagesinstalledonthesourcesystemare
inconsistentwiththissystem:
SUNWstosreg:notinstalled
(1.0,REV=2007.05.21.20.36)
Thesepatchesinstalledonthesourcesystemare
inconsistentwiththissystem:
119963:versionmismatch
(10)(11)
120812:versionmismatch
(25)(27)
8. Run the zoneadmattachcommand again to attach zone2 to newhost. This
time invoke the update on attach feature by specifying the ucommand line

option:
newhost#zoneadmzzone2attachu
Gettingthelistoffilestoremove
Removing15files
Remove2of2packages
Installing31files
Add2of2packages
Updatingeditablefiles
Thefile</var/sadm/system/logs/update_log>withinthezone
containsalogofthezoneupdate.

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.
17 Maintaining Solaris with Live Upgrade and Update On Attach Sun Microsystems, Inc.

.
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 Zones

When 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 earlier 4 (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 zoneadmlistcommand:
oldhost#zoneadmlistvic

IDNAMESTATUSPATHBRANDIP
0globalrunning/nativeshared
zone1configured/sharedzones/zone1nativeshared

zone2configured/sharedzones/zone2nativeshared
2. Run the zpoolimportcommand with no parameters to see whether the zpool
is available for import:
oldhost#zpoolimport
pool:sharedzonesid:9978900745171968029
state:ONLINE
action:Thepoolcanbeimportedusingitsnameornumeric
identifier.
config:
sharedzonesONLINE
c0d1ONLINE
3. Run the zpoolimportcommand using the zpool name:
oldhost#zpoolimportsharedzones
4. Run a zfslistcommand to check that the snapshot is available on oldhost:
oldhost#zfslist

NAMEUSEDAVAILREFERMOUNTPOINT
...
sharedzones4.19G15.4G4.14G/sharedzones
sharedzones@downrev46.3M4.13G
18 Maintaining Solaris with Live Upgrade and Update On Attach Sun Microsystems, Inc.

5. Try to attach zone1 to oldhost using the zoneadmattachcommand. 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#zoneadmzzone1attach
Thesepackagesinstalledonthissystemwerenotinstalled
onthesourcesystem:
SUNWstosreg(1.0,REV=2007.05.21.20.36)
Thesepatchesinstalledonthesourcesystemare
inconsistentwiththissystem:
119963:versionmismatch
(11)(10)
120812:versionmismatch
(27)(25)
6. Run the zfsrollbackcommand on the saved snapshot to revert it to its

previous state and make it possible to reattach both local zones to oldhost:
oldhost#zfsrollbacksharedzones@downrev
oldhost#zoneadmzzone1attach
oldhost#zoneadmzzone2attach