How to Migrate a Kernel Zone By Using Live Migration
Before You Begin
Ensure that both the kernel zone source and target hosts meet hardware, software, and storage requirements for live migration as detailed in Live Migration Requirements.
-
Obtain administrative rights for live migration.
For more information, see Authorizing Non-Root Users to Perform Kernel Zone Live Migration Operations. You also need the Service Configuration rights profile to run the service commands.
- Configure SSH authentication to not require an interactive prompt between the source and target hosts.
-
Test SSH authentication by executing a command such as
date on the target host.
global1$ ssh global2 date Mon Mar 9 13:22:40 PDT 2015
If you are prompted for a password, you have not configured your key pairs to enable login without interactive authentication.
-
Start the kernel zone migration service on the source and target
hosts.
global1$ svcadm enable -rs svc:/network/kz-migr:stream global1$ ssh global2 svcadm enable -rs svc:/network/kz-migr:stream
-
Check the status of RAD services on the source and target hosts.
The required services depend on which RAD URI you intend to use. If you will use ssh to migrate, the svc:/system/rad:local service must be running. If you will use rads, the svc:/system/rad:remote service must be running.
global1$ svcs rad STATE STIME FMRI disabled 14:47:31 svc:/system/rad:remote online 17:28:50 svc:/system/rad:local online 17:28:56 svc:/system/rad:local-http global1$ ssh global2 svcs rad STATE STIME FMRI disabled Jul_01 svc:/system/rad:remote online Jul_01 svc:/system/rad:local-http online Jul_01 svc:/system/rad:local
- (Optional)
Start any disabled RAD services you require on the source and target
hosts.
For example to enable the svc:/system/rad:remote service:
global1$ svcadm enable -rs svc:/system/rad:remote global1$ ssh global2 svcadm enable -rs svc:/system/rad:remote
-
Check the status of the NTP service on the source and target hosts.
global1$ svcs ntp STATE STIME FMRI online 11:09:40 svc:/network/ntp:default global1$ ssh global2 svcs ntp STATE STIME FMRI online 11:09:45 svc:/network/ntp:default
If the NTP service is not online, see Enhancing System Performance Using Clock Synchronization and Web Caching in Oracle Solaris 11.3 for information about how to set it up.
-
On the source host, confirm that the zone to be migrated is in the
running state.
global1$ zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / solaris shared 1 kzone1 running - solaris-kz excl - kzone2 installed - solaris-kz excl
-
Initiate a dry run of the live migration.
Caution - Perform this step to prevent live migration failure. After running this test, correct any configuration conflicts between the source and target systems that the dry run identifies. Example 29, Showing Output for a Failed Live Migration Dry Run illustrates an unsuccessful dry run and its configuration correction.
The zoneadm migrate -n command on the source system tests the kernel zone configuration.
global1$ zoneadm -z zonename migrate -n ssh://target-host
For example, the following output shows a successful dry run between the source system global1 and the target system global2:
root@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': Cleaning up. zoneadm: zone 'kzone1': Dry-run migration successful.
-
Correct any failures of the dry run.
For examples, see Example 31, Clearing the pagesize-policy Property Before Migration and the troubleshooting section at the end of the procedure.
-
Migrate the kernel zone.
Migrate the kernel zone using zoneadm migrate.
$ zoneadm -z zonename migrate target
For example, to migrate kzone1 from the source host global1 to the target host global2:
root@global1:~# zoneadm -z kzone1 migrate 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': Starting migration. zoneadm: zone 'kzone1': Suspending zone on source host. zoneadm: zone 'kzone1': Waiting for migration to complete. zoneadm: zone 'kzone1': Halting and detaching zone on source host. zoneadm: zone 'kzone1': Migration successful.
-
Confirm that the zone has migrated and is now running on the target
host.
root@global2:~# zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / solaris shared 1754 kzone1 running - solaris-kz excl - kzone2 configured - solaris-kz excl - kzone3 installed - solaris-kz excl - kzone4 configured - solaris-kz excl
- (Optional)
On the source host, confirm that the zone that was migrated is in the
configured state.
global1$ zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / solaris shared - kzone1 configured - solaris-kz excl - kzone2 installed - solaris-kz excl
Note - If you later boot the source host into a boot environment (BE) that was created before the live migration, the state of the migrated kernel zone might show as unavailable instead of configured because the zone state is not shared across BEs. Issue the following command to detach the zone's storage and return the zone's state to configured.$ zoneadm -z zonename detach -F
This example demonstrates a failed dry run between the source host global1 and the target host global2. The virtual-cpu resource is inconsistent between both hosts. See Oracle Solaris Zones Configuration Resources for further information about zone configuration.
global1$ zoneadm -z kzone1 migrate -n ssh://global2 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': boot failed: zone 'kzone1': error: Suspended zone has 8 active VCPUs, more than the configured zone 'kzone1': virtual-cpu maximum of 4. zone 'kzone1': error: Correct errors, or delete the configuration, using zonecfg(1M) on the zone 'kzone1': destination host. zoneadm: zone kzone1: call to zoneadmd(1M) failed: zoneadmd(1M) returned an error 9 (zone state change failed)Example 30 Live Migration Between Hosts With Two Different anet Configurations
The following example demonstrates preparing for live migration between hosts with different anet configurations. The configuration for the zone kzone1 on global1 is not suitable on the target host global2. On global2 the zone must use net1 for its anet resource. The configuration is exported to the target host and modified, then the pre-flight check is performed.
See Oracle Solaris Zones Configuration Resources for additional information regarding anet resources.
global1$ zonecfg -z kzone1 -r export | ssh root@global2 zonecfg -z kzone1 -f - global1$ ssh root@global2 zonecfg -z kzone1 'select anet 0; set lower-link=net1;end' global1$ zoneadm -z kzone1 migrate -n ssh://global2Example 31 Clearing the pagesize-policy Property Before Migration
This example shows how to clear the pagesize-policy property to prepare for migrating a kernel zone to a target system that does not support the property or that has a smaller page size than the source system. The administrator has already done a dry run that identified that the platforms have different largest page size.
global$ zonecfg -z kzone1 zonecfg:kzone1> select capped-memory zonecfg:kzone1:capped-memory> clear pagesize-policy zonecfg:kzone1:capped-memory> end zonecfg:kzone1> commit
Troubleshooting
Example 29, Showing Output for a Failed Live Migration Dry Run.
Example 31, Clearing the pagesize-policy Property Before Migration
zoneadm(1M) man page
To prevent live migration from failing, you should do a dry run of the migration first to see if the migration is correctly configured. For examples and more information, see:
Rarely, you might set pagesize-policy=largest-only to prevent booting unless the largest page size is used. This might be useful for a kernel zone that hosts a database or other application where the largest page size enhances performance.