Go to main content

Creating and Using Oracle® Solaris Zones

Exit Print View

Updated: August 2018
 
 

Migration and Transformation of Non-Global Zones

Migration means the moving of a zone to a new location. Transformation means converting the zone to an archive that can be deployed widely. Oracle Solaris provides the zonep2vchk tool to assist in zone transformations.

About Cold Migration of solaris Zones

A zone migration is the process of transferring an existing zone configuration and data from one host system to another host system. Zone migrations can only be performed for zones on shared storage. Zone migration can be cold, warm, or live. However, because solaris zones depend on the host's kernel, the zones cannot be running during migration to a new host. Therefore, warm migration and live migration are not supported for a solaris zone.

Cold migration occurs when the zone is not running on the source host while the zone is migrated. During cold migration, the zone is detached from storage, and a small amount of data is moved to the new host. When the zone is attached on the new host, it attaches the shared storage and the zone data is accessed using the same path. Cold migrations take approximately the same amount of time as a zone detach followed by an attach.

For additional information about shared storage, see Oracle Solaris Zones on Shared Storage. See About Zone Migration in Introduction to Oracle Solaris Zones for more information about zone migration and zone migration types.

Zone Migration Configuration Requirements

Before migrating, you need to consider configuration and host requirements, and package updates.

  • Zone state – The zone's state must be installed when you begin the migration. After migration, the state will still be installed on the new host.

  • Shared storage – If the zone is not on shared storage, you can use Unified Archives to move the zone, similar to a zone transformation. See About Zone Transformations.

  • User authorizations – Migrations must be performed by a user or role that has the Zone Migration and Zone Configuration profiles. You can authorize specific non-root users to perform migrations. See Authorizing Non-Root Users to Perform Non-Global Zone Migrations for more information.

Zone resources – A solaris zone configuration must meet the following resource requirements to be migrated:

device Resource Type

Any device resources must be specified with storage URI. The match property cannot be set.

fs, dataset Resource Types

The fs and dataset resources are not allowed for cold migration because they refer to local file systems or local devices.

npiv:over-hba Resource Type Property

The npiv:over-hba property can only be set if the zone exists on the target system. This is not a portable setting because it is bonded to a physical controller number, which might not be consistent between the source and target systems. However, if the zone configuration exists on the target system before the migration, it is assumed that you have set up the systems so that the controller numbers are consistent and migration should be allowed.

rootzpool, zpool Resource Types

The rootzpool and zpool resources must be specified with shared storage resources using iscsi and lu URIs

zoneadm migrate Command

The zoneadm command is used with the migrate subcommand for migration. The format of the command for a solaris zone is as follows:

zoneadm –z zonename migrate [–nq] [–t auto] [-u | -U] [–z ZBE] \
[-x destroy-orphan-zbes | force-zbe-clone | deny-zbe-clone |
attach-last-booted-zbe | attach-matched-zbe | attach-last-mounted-zbe] ] \
ssh|rads|radg://user@host:port

The zoneadm migrate command options include the following:

–n

Performs a non-executing dry run of the migration. The dry run checks that the shared storage resource is accessible from both systems.

The zone configuration is not checked for compatibility with the target host. You can adjust the configuration on the target host after migration before booting the zone, if necessary.

–q

Quiet mode, which specifies that the status is not reported during migration operations.

–t auto

Specifies the type of migration to perform. For a solaris zone, only the auto value, to specify a cold migration, is supported. Additional options might be available as brand-specific options.

-u | -U

The –u and –U options are mutually exclusive.

  • The –u option updates the minimum number of packages needed in the migrated zone to match the global zone after attachment. A new zone boot environment (ZBE) might be created during the update attempt.

  • The –U option updates all packages in the migrated zone to match the global zone after attachment. A new ZBE might be created during the update attempt.

-x extended-option

Specifies an extended options to perform when attaching the zone to the target host. Possible extended options are as follows:

attach-last-booted-zbe

Attaches the ZBE that was last booted.

attach-last-mounted-zbe

Attaches the most recently mounted ZBE, which has the latest changes, on the target host zonepath. This is the default behavior if no -z ZBE selection option or -x option is given.

attach-matched-zbe

Attaches the ZBE that matches the current global zone BE on the target host.

If the selected ZBE is associated with a global BE that is different from the current global BE, a clone of the ZBE is created and attached. The –x option is used to specify one of the following options for ZBE clone handling upon attachment of the ZBE:

deny-zbe-clone

Overrides the cloning of the selected zone boot environment. This option forces the selected ZBE to be attached to the zone without cloning, if the default behavior is to clone it. Otherwise it has no effect.

If the -x deny-zbe-clone option is used during attach of a solaris zone, the selected zone boot environment is updated in place and mounted as the active boot environment without cloning. The ZBE can be an orphaned boot environment.

destroy-orphan-zbes

Destroys all zone boot environments that are not associated with any global zone.

force-zbe-clone

Forces the selected zone boot environment to be cloned. The new cloned boot environment is then selected to be attached to the zone.

If the -x force-zbe-clone option is used during attach of a solaris zone, the selected zone boot environment is cloned and the clone is mounted as the active boot environment. The ZBE can be an orphaned boot environment.

See About Orphaned Zone Boot Environments and Clones for more information about ZBE attachment and cloning.

–z ZBE

Specifies the name of a particular zone boot environment to be attached and updated. If the specified ZBE is associated with a different global zone, the specified ZBE is cloned and the clone ZBE is attached.

If no ZBE is specified to attach, the ZBE that was most recently mounted on the zonepath is attached, regardless of the current global ZBE.

You can also use the –x option to specify attach ZBE behavior instead of the -z ZBE option.

ssh | rads | radg://user@host:port

Specifies a RAD URI including the scheme, user name, and host name to be used to migrate the zone to the target host. The ssh scheme uses Secure Shell and the rads scheme uses TLS. The radg scheme uses the Generic Security Services API (GSS-API). Specify radg if the RAD client and target host have been configured for Kerberos.

If you only specify a host name, the scheme defaults to rads, user defaults to the current user, and port defaults to the standard RAD port 12302.

See Connecting in Python to a RAD Instance by Using a URI in Remote Administration Daemon Client User’s Guide for more information.

Refer to the zoneadm(8) man page for more information about the zoneadm migrate command.

Zone Migration and Various Host Configurations

    Observe the following guidelines concerning the source host and target host of a zone migration:

  • If you are migrating a zone to an identical system and all storage references use a storage URI that is accessible by both hosts, the migrated configuration should be compatible without changes. If the target system is not identical, you must modify the configuration on the target system after migration to suit the new system.

  • If the zone storage is local, you cannot use the zoneadm migrate command. You can instead do one of the following:

  • If you configure the zone on the target host before migration, the target host's version of the zone configuration is used to boot the zone.

  • If you do not configure the zone on the target host before migration, the zone configuration is exported from the source host and imported on the target host. The user performing the migration must have the Zone Configuration rights profile and solaris.zone.config authorization to create zone configurations on the target host. See Authorizing Non-Root Users to Perform Non-Global Zone Migrations for more information.

Zone Migration and Package Updates

solaris zones always have their storage mapped and zpools imported, even in an attached state. This is necessary so that packages in the zone can be updated when the global zone is updated. When a solaris zone is attached on the target system during migration, the packages in the zone are verified against the global zone and the attach fails if the package levels are different, unless you specify to attempt to update the zone with the –u or –U update option.

A migration using a –u or –U update option attempts to update the packages in the solaris zone to match the global zone. During that attempt a new ZBE might be created.

If no -x attach-*-zbe option is given to zoneadm migrate, the attach on the destination system selects the most recently mounted ZBE to be cloned. The cloned ZBE is then attached.

About Zone Transformations

Zone transformation or zone conversion is the process of creating an archive of an Oracle Solaris global zone or non-global zone and deploying it as an Oracle Solaris global zone or non-global zone. The source zone type (global or non-global) might be the same as or different than the deployed zone type (global or non-global).

    You can perform the following types of zone transformations:

  • Global zone to non-global zone. Called a physical to virtual or P2V conversion.

  • Non-global zone to global zone. Called a virtual to physical conversion.

  • Non-global zone to non-global zone. Called a virtual to virtual or V2V conversion. This transformation is useful for migrating a zone that is not using shared storage and thus cannot be migrated by using the zoneadm migrate command.

Oracle Solaris supports several virtualization technologies. For example, both logical domains and zones are virtual Oracle Solaris instances. Transformation of a logical domain to a zone can be considered a V2V conversion. However, because a logical domain is running a global zone, it is also a global to non-global conversion, which is a P2V conversion. For this reason, the model of zone transformation on Oracle Solaris 11 is usually discussed in terms of global versus non-global, instead of physical versus virtual.

In the Oracle Solaris 11.4 release, you can use only Unified Archives to transform to and from zones. See Using Unified Archives for System Recovery and Cloning in Oracle Solaris 11.4 for more information about Unified Archives.

Zone transformations are implemented by archiving the Oracle Solaris instance that you want to convert and deploying the archive into the new zone or system.

On host systems running Oracle Solaris 11 releases prior to Oracle Solaris 11.2, you must use legacy archives for zone conversion, as documented in those earlier releases.

Zone Transformations Using Oracle Solaris Unified Archives

Unified Archive files contain both zone configuration and zone data. This means that on the target system a zone can be configured and installed from the archive. You can use the zonecfg command to configure and the zoneadm command to install new zones directly from a Unified Archive file. See Using Unified Archives for System Recovery and Cloning in Oracle Solaris 11.4 for a full description of Unified Archives, including usage for system and zone cloning and recovery.

    The overall process for zone transformation is as follows:

  1. Ensure that both the source host and the target host where the new zone will be located meet requirements. See Zone Transformation Requirements for Source and Target Hosts for more information.

  2. If transforming a global zone to a non-global zone, use the zonep2vchk tool to identify any issues that might cause problems in the transformed zone. See Using the zonep2vchk Tool to Prepare for Global to Non-Global Transformations for more information.

  3. Create an archive of the global zone by using the archiveadm command.

  4. Create the target zone configuration by using the zonecfg command.

  5. Install the zone from the archive by using the zoneadm command, or install a system from the archive by using the installadm command.

For more information, see the zonep2vchk(8), archiveadm(8), zfs(8), zonecfg(8), and zoneadm(8), and zones(7) man pages.

Zone Transformation Requirements for Source and Target Hosts

Transformation of solaris zones has the following requirements:

  • Architecture – The source and target systems must use the same instruction set architecture (ISA). For example, they must both be SPARC based systems, or must both be x86 based systems.

  • Oracle Solaris versions –The global zone on the target system must be running an Oracle Solaris release that is equal to or higher than that on the original source host.

    • Before you transform a global zone to a non-global zone, verify that the software running in the global zone is compatible with non-global zones. The zonep2vchk(8) tool evaluates a global zone's configuration before transformation to a non-global zone.

    • Before you transform a non-global zone to a global zone or kernel zone, you must ensure that the Oracle Solaris operating system versions of the source and target hosts are compatible. You do not need to check for additional compatibility. Any software running in the non-global zone can also run in a global zone or kernel zone, provided that the host systems are compatible.

  • Oracle Solaris packages – To ensure that the zone will run properly, the target system must have the same or later versions of the required operating system packages as those installed on the original source host. For example, if the source host is running a Support Repository Update (SRU), then the target must also be running that SRU or a later SRU.

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

Zone Transformations From Systems That Contain Non-Global Zones

When you transform a global zone to a non-global zone, any existing solaris zones or kernel zones that are within that global zone will not be usable after the zone is transformed. Only global zones and kernel zones can contain other zones.


Tip  -  To retain the solaris zones or kernel zones before you transform the global zone, create separate recovery archives for each individual zone. Then you can redeploy the zones from those archives on a new system. For example, you could first create archives for the non-global zones. Then, you could archive the global zone.

For more information, see Chapter 1, Oracle Solaris System Recovery and Cloning (Overview) in Using Unified Archives for System Recovery and Cloning in Oracle Solaris 11.4.

Using the zonep2vchk Tool to Prepare for Global to Non-Global Transformations

The zonep2vchk tool evaluates a global zone's configuration before transformation to a non-global zone. The primary documentation for the tool is the zonep2vchk(8) man page.

About the zonep2vchk Tool

The zonep2vchk tool evaluates a global zone, or physical instance, for potential issues that can occur when it is converted to a non-global zone, or virtual instance. The zonep2vchk tool can be run with an effective user id of 0.

    The zonep2vchk tool does the following:

  • Identifies problem areas in the source system's configuration

  • Minimizes the manual reconfiguration effort required

  • Supports conversion of Oracle Solaris global zones into non-global zones on the same Oracle Solaris releases

  • Supports complex network configurations in the original system image, including multiple IP interfaces, IP multipathing, and VLANs

Use the zonep2vchk tool to assist in the transformation of an Oracle Solaris global zone to a non-global zone. The tool evaluates the system to flag any issues that might complicate or prevent transformation to a solaris brand zone, and makes suggestions for actions to take to enable conversion. The tool can also provide a template for the new solaris zone configuration.

Figure 2  zonep2vchk Evaluation Scenarios

image:Figure shows using zonev2pchk to aid physical system transformation to a zone on an                 Oracle Solaris system

Checks Performed by the zonep2vchk Tool

    You can use zonep2vchk options to perform several types of checking:

  • Basic analysis checks for Oracle Solaris features in use that might be impacted by global to non-global transformation. This is the default if you specify no options.

    Use the –b option for basic checking when combined with other options.

  • Static analysis inspects binaries for system and library calls that might not function in a zone.

    Use the lowercase –s option to specify paths for binaries to analyze, or use the uppercase –S option to specify the path to a file that lists the files and directories to analyze.

  • Runtime analysis inspects the currently executing applications for operations that might not function in a zone.

    Use the –r option with a specified duration in hours, minutes, or seconds, or the –x option to analyze until you send a signal interrupt such as by typing Ctrl-C.

For more information, see How to Check the Source System With zonep2vchk and the zonep2vchk(8) man page.

Issues Highlighted by the zonep2vchkTool

    The zonep2vchk tool produces the following main categories of information when you run the various checks:

  • Issues that can be addressed with a specific zone configuration or with configuration changes in the global zone

  • Identification of functions that cannot work inside a zone

For example, if an application sets the system clock, that ability can be enabled in a solaris zone by adding the appropriate privilege to the zone. However, an application that accesses kernel memory cannot run in a solaris zone. The output distinguishes between these two classes of issues.

By default, the zonep2vchk tool prints messages in human readable form. To print messages in machine parsable form, use the –P option. For more information, see the zonep2vchk(8) man page.

Zone Configuration Template for a Transformed Zone

The zonep2vchk tool provides a –c option that you can use to create a template for use with the zonecfg command. The template configures some of the global zone's resources appropriately for the non-global zone.

You can run the analysis checks and make any necessary changes in the global zone before creating the template. You can create the template by running the command and directing the output to a file which can then be used as input to the zonecfg command to create a starting point for the zone configuration. For example:

global$ pfbash zonep2vchk -c > myzone.config
global$ zonecfg -z myzone -f myzone.config