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.
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.
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:
Any device resources must be specified with storage URI. The match property cannot be set.
The fs and dataset resources are not allowed for cold migration because they refer to local file systems or local devices.
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.
The rootzpool and zpool resources must be specified with shared storage resources using iscsi and lu URIs
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:
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.
Quiet mode, which specifies that the status is not reported during migration operations.
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.
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.
Specifies an extended options to perform when attaching the zone to the target host. Possible extended options are as follows:
Attaches the ZBE that was last booted.
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.
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:
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.
Destroys all zone boot environments that are not associated with any global zone.
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.
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.
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.
Refer to the zoneadm(8) man page for more information about the zoneadm migrate command.
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:
Remove local storage devices from the zone configuration if they are not needed for booting, and then use zoneadm migrate.
Convert the storage to shared as described in How to Move a Zone To a Shared Storage Configuration in Creating and Using Oracle Solaris Zones, and then use zoneadm migrate.
Archive the zone and redeploy on the new system instead of migrating as described in Archiving and Moving Non-Global Zones That Are Not Using Shared Storage.
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.
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.
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.
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:
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.
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.
Create an archive of the global zone by using the archiveadm command.
Create the target zone configuration by using the zonecfg command.
Install the zone from the archive by using the zoneadm command, or install a system from the archive by using the installadm command.
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.
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.
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.
This section provides the following information:
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
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.
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.
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