Go to main content

Creating and Using Oracle® Solaris Kernel Zones

Exit Print View

Updated: August 2021
 
 

Kernel Zone Migration Preparation

Before you migrate kernel zones, review the zoneadm migrate command, learn how to make the source and target zones compatible, consider the effects of any differences in CPUs and OS versions, and plan to use the encryption defaults to ensure security during the migration process.

About the zoneadm migrate Command

The zoneadm command that is used for each migration method is similar. The migration process is determined by the state of the zone that you are migrating. The format of the command is as follows:

zoneadm –z kzone migrate [–nqw] -c cipher] [–t {auto|live}][ [ssh|rads|radg://user@host:port]

where:

–c cipher

Specifies a secure cipher option for migrations. By default, migrations are secured using a cipher that is supported on both systems even if you do not specify a particular cipher. See Secure Migration.

–n

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

  • For live migration, the dry run checks for full compatibility so if it passes the checks, the zone will successfully resume on the remote system.

  • For warm migration, even though settings such as CPU and memory must be compatible, the dry run does not check them because the zone is not running during the migration. After the migration, you can adjust the settings as needed before resuming.

  • For cold migration and warm migration, the dry run does not check for CPU compatibility or compare the zone configuration on the source system against any existing zone configuration on the target system. For cold migration, there is no need to check for CPU and memory compatibility and so on since the zone is booting from scratch, After the migration, you can adjust the zone configuration settings as needed.

–q

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

–t {live | auto}

Specifies the type of migration. The default value of –t is auto which enables the zoneadm migrate command to automatically determine which type of migration is appropriate based on the zone's state. The –t live option enables you to restrict migration to running zones only. If you specify –t live for a zone that is not running, no migration takes place for that zone.

–w

Uses the zone configuration from the source system. By default, the zone configuration from the source is ignored in favor of the zone configuration on the target. The –w option is mutually exclusive with the –n 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 system. The ssh scheme uses SSH 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 are configured for Kerberos.

If you specify only 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 migrate command.

About Migration and Compatible Configurations

A kernel zone's configuration must be completely compatible with the migration target host's environment, as if you were detaching then attaching the zone. A zone that boots on a new host after a warm or live migration is resuming from a saved memory state and is expecting a particular setup. Any incompatibilities cause migration to fail.

If you are migrating a kernel zone to another system that is identical, and all storage references use a storage URI that is accessible by both hosts, the migrated configuration should be compatible without changes.

If the zone storage is local, you cannot use the zoneadm migrate command. You can either remove local storage devices from the zone configuration if they are not needed for booting, or 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.

Alternatively, you can move the zone using a unified archive. See Using Unified Archives for System Recovery and Cloning in Oracle Solaris 11.4 for more information.

    The following resources and properties must be the same in the zone configuration on the source and target hosts:

  • Amount of memory specified for the capped-memory:physical value

  • Value of the capped-memory:pagesize-policy property.

  • Number of virtual CPUs specified for virtual-cpu:ncpus

  • Shared storage URI and id for disk devices specified with the device resource

  • Properties of virtual NICs specified with net or anet resources

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 the configuration is incompatible with the current zone configuration, an error is returned. The encryption keys for the zone must also match. See Encryption Keys and Host Data.

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.configuration authorization to create zone configurations on the target host. See Rights Required to Perform Kernel Zone Migrations for more information.

Preparation for Migrating Kernel Zones to Systems With Different CPUs or OS Versions

Kernel zones can be migrated to other host systems that have different CPUs but are the same platform. For example, you can migrate a kernel zone from a SPARC T4 server to a SPARC T7 server, or from an Intel Nehalem-based server to a server based on a Haswell processor. This is called cross-CPU migration. You cannot migrate a zone from a SPARC-based environment to an x86-based environment.

If you want to migrate a kernel zone to a target system whose processor is different from the source system, you must prepare the kernel zone and reboot it before you suspend the zone for warm migration or live migrate.

On SPARC-based and Intel-based systems, you can use the cpu-arch resource type to specify a migration class that defines a common set of processor features to enable the zone to run well on the source and target system.

The cpu-arch resource type is not available for AMD systems.

On SPARC-based systems only, you can additionally set a compatibility level with the host-compatible resource type to ensure that Oracle Solaris features that are enabled by specific processors are supported at the same level in the global zones of the source and target host. If host-compatible is not set, only Oracle Solaris 11.2 features are visible to the zone. Oracle Solaris 11.2 is the earliest version of Oracle Solaris that can run in a kernel zone, but does not support features such as SSM and DAX.


Note -  The cpu-arch and host-compatible values in the zone configuration must be supported by the Oracle Solaris release that is running on both source and target hosts in order for live migration to succeed. A zone cannot be live migrated between hosts when a feature is enabled in a different way, even when the feature is supported by both releases.

For example, if host-compatible=adi is set in the zone configuration on the source host and host-compatible=level1 is set in the zone configuration on the target host, the live migration fails even if both hosts are running Oracle Solaris 11.4.


See Kernel Zone Migration Class and Host Compatibility Level (solaris-kz Only) in Oracle Solaris Zones Configuration Resources for further information about the cpu-arch and host-compatible resource type properties for migration between different SPARC architectures.

See Cross-CPU Migration Classes (solaris-kz) in Oracle Solaris Zones Configuration Resources for more information about setting the cpu-arch resource type for migration between different Intel architectures.

If the kernel zone's cpu-arch property is not set to a migration class, the kernel zone's CPU architecture is the same as the host system.


Note -  The kernel zone host will always refuse to resume a kernel zone that was previously suspended on an incompatible CPU type. A kernel zone will not boot if the cpu-arch class is set to an incompatible value.
Example 34  Confirming and Setting the Kernel Zone cpu-arch and host-compatible Resources on a SPARC Based System

The following example demonstrates how to confirm and set the cpu-arch and host-compatible resource types on the kernel zone kzone1.

global$ zonecfg -z kzone1
zonecfg:kzone1> info cpu-arch host-compatible
cpu-arch: generic
host-compatible: native
zonecfg:kzone1> set cpu-arch=migration-class1
zonecfg:kzone1> set host-compatible=adi
zonecfg:kzone1> info cpu-arch host-compatible
cpu-arch: migration-class1
host-compatible: adi
zonecfg:kzone1> exit
Example 35  Live Migration Fails Due to Incompatible SPARC CPU Architecture

This example demonstrates a live migration attempt between a SPARC T4 host global1 and a SPARC T5 host, global2. The cpu-arch property is using a default value that indicates the actual CPU architecture. The cpu-arch property value is not consistent across the hosts and must be set to a migration class described in Kernel Zone Migration Class and Host Compatibility Level (solaris-kz Only) in Oracle Solaris Zones Configuration Resources.

global1$ zoneadm -z kzone1 migrate -n ssh://global2
zoneadm: zone 'kzone1': Importing zone configuration.
zoneadm: zone 'kzone1': Attaching zone.
zoneadm: zone 'kzone1': Booting zone in 'migrating-in' mode.
zoneadm: zone 'kzone1': Checking migration compatibility.
zoneadm: zone 'kzone1': configuration check failed:
error: Cannot resume guest on target host.     
error: Guest's migration class is SPARC-T4, host's is SPARC-T5. Please check cpu-arch setting in zone config or in host LDom config.
2016-08-18 18:27:53 error: request failed: failed to create VM: Operation not supported
Example 36  Confirming and Setting the Kernel Zone Migration Class on an Intel System

The following example demonstrates how to confirm and set the cpu-arch resource type on the kernel zone kzone1.

global$ zonecfg -z kzone1
zonecfg:kzone1> info cpu-arch
cpu-arch: generic
zonecfg:kzone1> set cpu-arch=migration-class4
zonecfg:kzone1> info cpu-arch
cpu-arch: migration-class4
zonecfg:kzone1> exit
global$ zoneadm kzone1 reboot
Example 37  Live Migration Fails Due to Incompatible Intel CPU Architecture

This example demonstrates a live migration attempt between a Haswell-based host global1 and a Sandy Bridge-based host global2. This would occur if you were migrating for example from an Oracle Server X5-2 to a different type of server whose CPU is a Sandy Bridge processor and you did not set cpu-arch. The cpu-arch property must be set to a migration class described in Cross-CPU Migration Classes (solaris-kz) in Oracle Solaris Zones Configuration Resources.

global1$ zoneadm -z kzone1 migrate -n ssh://global2
zoneadm: zone 'kzone1': Importing zone configuration.
zoneadm: zone 'kzone1': Attaching zone.
zoneadm: zone 'kzone1': Booting zone in 'migrating-in' mode.
zoneadm: zone 'kzone1': Checking live migration compatibility.
zoneadm: zone 'kzone1': configuration check failed:
See /var/log/zones/kzone1.messages for debug output
error: cannot resume as current CPU migration class value: sandybridge does not match the suspended value haswell
2016-08-15 01:05:55 error: request failed: failed to create VM: Invalid argument

Secure Migration

By default, migration memory transfer data is encrypted when transferring between source and target hosts using an encryption cipher that is supported on both hosts. You can use zoneadm migrate -c cipher to specify a particular encryption cipher or disable encryption. cipher can be one of the following values:

encryption-cipher

Specifies one of the ciphers that is supported on the source and target hosts.

list

Lists supported ciphers on the source and target hosts.

none

Disables encryption.

If you do not specify a cipher, a cipher is automatically chosen based upon its support on both the source and target hosts.

Example 38  Live Migration Between Two Trusted Hosts

The following example demonstrates a live migration of the kernel zone kzone1 from the source host global1 to the destination host global2.

global1$ zoneadm -z kzone1 migrate root@global2
    Password: 
    zoneadm: zone 'kzone1': Using existing zone configuration on destination.
    zoneadm: zone 'kzone1': Attaching zone.
    zoneadm: zone 'kzone1': Booting zone in 'migrating-in' mode.
    zoneadm: zone 'kzone1': Checking migration compatibility.
    zoneadm: zone 'kzone1': Starting migration.
    zoneadm: zone 'kzone1': Suspending zone on source host.
    zoneadm: zone 'kzone1': Waiting for migration to complete.
    zoneadm: zone 'kzone1': Migration successful.
    zoneadm: zone 'kzone1': Halting and detaching zone on source host.
Example 39  Confirming Cipher Compatibility Between Live Migration Source and Destination Hosts

The following example demonstrates an attempt to perform a live migration of the kernel zone kzone1 from the source host global1 to the destination host global2. The specified cipher aes-128-cbc is not supported on the destination host.

global1$ zoneadm -z kzone1 migrate -c aes-128-cbc ssh://global2
zoneadm: zone 'kzone1': cipher aes-128-cbc not supported by destination
zoneadm: zone 'kzone1': destination supports: aes-128-ccm aes-128-gcm
Example 40  Listing Available Supported Ciphers on Live Migration Source and Destination Hosts

The following example lists the available supported ciphers during a live migration of the kernel zone kzone1. The zone is migrated from the source host global1 to the destination host global2.

global1$ zoneadm -z kzone1 migrate -c list root@global2
    Password:
    source ciphers: aes-128-ccm aes-128-gcm none
    destination ciphers: aes-128-cbc
    # echo $?
    0

Tip  -  To prevent loss of the encryption key that is required to boot a migrated kernel zone, use the zonecfg export command on the source system to generate a command file to be used on the target system. For example:
global$ pfbash zonecfg -z kzone1 export -f /net/example/path/kzone1.cfg
global$ zonecfg -z kzone1 -f /net/example/path/kzone1.cfg

For information about the encryption keys that enable the zone to boot, see Encryption Keys and Host Data.