Chapter 23 Moving and Migrating Non-Global Zones (Tasks)

This chapter is new for the Solaris 10 11/06 release. Additional features
have been added in subsequent releases.

This chapter describes how to:

Move an existing non-global zone to a new location on the
same machine

Validate what will happen in a non-global zone migration before
the actual migration is performed.

Migrate an existing non-global zone to a new machine

Use the zoneadmdetach and zoneadmattach commands to update a zone that
has a lower patch level to the level of a global zone at a higher patch level.

Starting with the Solaris 10 10/08 release, if the new host has the
same or later versions of the zone-dependent packages and associated patches,
using zoneadmattach with the -u option
updates the minimum set
of packages to make
the non-global zone usable on the new host. If the new host
has a mixture of higher and lower version patches as compared to the source
host, then an update during the attach operation is not allowed.

The zoneadmattach command used with the -u option also enables migration between
machine classes, such as from sun4u to sun4v.

Starting with the
Solaris 10 9/10 release, using zoneadmattach with
the -U option updates all of the packages for the zone, so
that these packages match what would be seen with a newly installed non-global
zone on this host. Any packages installed inside the zone but not installed
in the global zone are ignored and left as-is. This option also enables automatic
migration between machine classes, such as from sun4u to sun4v.

As an alternative to normal patching, the zones
can be detached while the global zone is patched, and then reattached with
the -U option to match the patch level of the global zone.

Solaris 10 11/06: Moving a Non-Global Zone

This procedure is used to move the zone to a new location on the same
system by changing the zonepath. The zone must be halted.
The new zonepath must be on a local file system. The normal zonepath criteria described in Resource and Property Types apply.

How to Move a Zone

You must be the global administrator in the global zone to perform this
procedure.

About Migrating a Zone

New
information has been added to this section since the Solaris 10 11/06 release.

The zonecfg and zoneadm commands
can be used to migrate an existing non-global zone from one system to another.
The zone is halted and detached from its current host. The zonepath is
moved to the target host, where it is attached.

The following restrictions apply to zone migration:

The global zone on the target system must be running the same
Solaris release as the original host.

To ensure that the zone will run properly, the target system
must have the same versions of the following required operating system packages
and patches as those installed on the original host.

Packages that deliver files under an inherit-pkg-dir resource

Packages where SUNW_PKG_ALLZONES=true

Other packages and patches, such as those for third-party products,
can be different.

Solaris
10 10/08: If the new host has later versions of the zone-dependent
packages and their associated patches, using zoneadmattach with the -u option updates those packages
within the zone to match the new host. The update on attach software looks
at the zone that is being migrated and determines which packages must be updated
to match the new host. Only those packages are updated. The rest of the packages,
and their associated patches, can vary from zone to zone. This option also
enables automatic migration between machine classes, such as from sun4u to sun4v.

Solaris 10 9/10: If the new host has later versions
of the packages and their associated patches, using zoneadmattach with the -U option updates those packages
within the zone to match what would be seen with a newly installed non-global
zone on this host. Any packages installed inside the zone but not installed
in the global zone are ignored, and left as-is. This option also enables automatic
migration between machine classes, such as from sun4u to sun4v.

Solaris
10 5/09: The -b option can be used to specify patches
to be backed out of the zone before the update.

The host and target systems must have the same machine architecture
unless the -u option, which can be used to migrate between sun4u and sun4v machine classes, is used.

Solaris 10 5/09:The -b option
can be used to specify patches, either official or Interim Diagnostics/Relief
(IDR), to be backed out of the zone during the attach. Multiple -b options
can be specified. If any of the patches cannot be backed out for any reason,
then the attach will fail and none of the patches will
be backed out.

This option only applies to zone brands using SVr4 packaging.

To verify the Solaris release and the machine architecture, type:

#uname -m

The zoneadmdetach process creates
the information necessary to attach the zone on a different system. The zoneadmattach process verifies that the target
machine has the correct configuration to host the zone.

Because there are several ways to make the zonepath available
on the new host, the actual movement of the zonepath from
one system to another is a manual process that is performed by the global
administrator.

When attached to the new system, the zone is in the installed state.

How to Migrate A Non-Global Zone

You
must be the global administrator in the global zone to perform this procedure.

The system administrator is notified of required actions to be taken
if either or both of the following conditions are present:

Required packages and patches are not present on the new machine.

The software levels are different between machines.

Solaris 10 10/08: Attach the
zone with a validation check and update the zone to match a host running later
versions of the dependent packages or having a different machine class upon
attach.

host2# zoneadm -z my-zone attach -u

Tip –

Solaris 10 10/08: If the source
system is running an older version of the Solaris system, it might not generate
a correct list of packages when the zone is detached. To ensure that the correct
package list is generated on the destination, you can remove the SUNWdetached.xml file from the zonepath. Removing this file will
cause a new package list to be generated by the destination system.

This
is not necessary with the Solaris 10 5/09 and later releases.

Solaris 10 9/10: Attach the zone with a validation
check and update all of the packages for the zone, so that these packages
match what would be seen with a newly installed non-global zone on this host.
Any packages installed inside the zone but not installed in the global zone
are ignored and left as-is.

host2# zoneadm -z my-zone attach -U

Solaris 10 5/09 and later: Also use the -b option
to back out specified patches, either official or IDR, during the attach.

host2# zoneadm -z my-zone attach -u -b IDR246802-01 -b123456-08

Note that you can use the -b option independently of
the -u or -U options.

Force the attach operation without performing the validation.

host2# zoneadm -z my-zone attach -F

Caution –

The -F option allows you to force the attach with no validation performed. This is useful in certain cases,
such as in a clustered environment or for backup and restore operations, but
it does require that the system be properly configured to host the zone. An
incorrect configuration could result in undefined behavior later.

How to Move the zonepath to a New
Host

There are many ways to create an archive of the zonepath.
For example, you can use the cpio or pax commands
described in the cpio(1))
and pax(1) man pages.

There are also several ways to transfer the archive to the new host.
The mechanism used to transfer the zonepath from the source
host to the destination depends on the local configuration. In some cases,
such as a SAN, the zonepath data might not actually move.
The SAN might simply be reconfigured so the zonepath is
visible on the new host. In other cases, the zonepath might
be written to tape, and the tape mailed to a new site.

For these reasons, this step is not automated. The system administrator
must choose the most appropriate technique to move the zonepath to
the new host.

Troubleshooting

Next Steps

If you have copied the data instead of reconfiguring a SAN, then the zonepath data will still be visible on the source host even though
the zone is now in the configured state. You can either manually remove the zonepath from the source host after you have finished moving the
data to the new host, or you can reattach the zone to the source host and
use the zoneadmuninstall command to
remove the zonepath.

Solaris 10 5/08: About Validating a Zone Migration
Before the Migration Is Performed

You
can perform a trial run before the zone is moved to the new machine by using
the “no execute” option,-n.

The zoneadmdetach subcommand
is used with the -n option to generate a manifest on a running
zone without actually detaching the zone. The state of the zone on the originating
system is not changed. The zone manifest is sent to stdout.
The global administrator can direct this output to a file or pipe it to a
remote command to be immediately validated on the target host. The zoneadmattach subcommand is used with the -n option
to read this manifest and verify that the target machine has the correct configuration
to host the zone without actually doing an attach.

The zone on the target system does not have to
be configured on the new host before doing a trial-run attach.

Solaris 10 5/08: How to Validate a Zone Migration
Before the Migration Is Performed

You must be the global administrator in the global zone to perform this
procedure.

Migrating a Zone From a Machine That Is not Usable

A machine that hosts a native Solaris zone
can become unusable. However, if the storage the zone lives on, such as a
SAN, is still usable, it might still be possible to migrate the zone to a
new host successfully. You can move the zonepath for the
zone to the new host. In some cases, such as a SAN, the zonepath data
might not actually move. The SAN might simply be re-configured so the zonepath is visible on the new host. Since the zone was not properly detached,
you will have to first create the zone on the new host using the zonecfg command. Once this has been done, attach the zone on the new host.
Although the new host will tell you the zone was not properly detached, the
system will attempt the attach anyway.

Using Update on Attach as a Patching Solution

The update on attach process developed for migrating zones to a
different system can also be used to patch zones. This method allows the global zone to be available
more quickly. The system administrator can then control which zones are updated
first and get those zones running before less critical zones are updated and
booted.

The following process updates all patches so that the zone
looks like a newly installed zone on the system:

Before applying a patch bundle to the global zone, detach
all of the non-global zones.

Apply the patch bundle to the global zone.

After the bundle has been applied and the system has been
rebooted, use the zoneadmattach command
with the -U option to bring the non-global zones up to the
same patch level as the global zone.

Any packages installed inside the zone
but not installed in the global zone are ignored and not affected.