X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Overwriting Zone configuration on migration and evacuation

Jan Pechanec
Senior Principal Software Engineer

When migrating/evacuating a zone for the first time, the zone configuration from the source host is copied over to the target host and is never overwritten there after that. That is by design to allow for tailoring the remote configuration to fit the target HW which might be different from the source host HW. For example, your target might be CPU constrained so the zone configuration there needs the pool resource.

For that reason, we chose to never overwrite an existing configuration when we delivered the feature in Oracle Solaris 11.4 release back in 2018. When we recently asked our customers whether they would have preferred to always overwrite the existing configuration on migration, the result was exactly split between those two approaches.

We have been asked a few times in the past to provide an option to overwrite an existing configuration on the target host for environments where the default behavior does not work that well. The only supported way to change an existing configuration on the target was to either manually export the config on the source and use it to recreate it on the target, or remove the configuration there and let the next migration/evacuation copy over the latest one.

The good news is that from Oracle Solaris 11.4 SRU 21, you can use the -w option to the migrate subcommand for the overwrite. The following is an example output for the live migration (works same with the cold migration though, for all Zone brands):

# zoneadm -z evac2 migrate -w ssh://target-host
zoneadm: zone 'evac2': Removing existing zone configuration on destination
zoneadm: zone 'evac2': Importing zone configuration.
zoneadm: zone 'evac2': Attaching zone.
zoneadm: zone 'evac2': Booting zone in 'migrating-in' mode.
zoneadm: zone 'evac2': Checking live migration compatibility.
zoneadm: zone 'evac2': Performing initial copy (total 8192MB).
zoneadm: zone 'evac2': 0.00% done: 0MB copied @ 0.0MB/s, skipped 0MB
zoneadm: zone 'evac2': 35.35% done: 2688MB copied @ 537.6MB/s, skipped 208MB
zoneadm: zone 'evac2': 71.70% done: 5504MB copied @ 563.2MB/s, skipped 369MB
zoneadm: zone 'evac2': 100.00% done: 7568MB copied @ 412.8MB/s, skipped 623MB
zoneadm: zone 'evac2': Performing copy of recently modified memory.
zoneadm: zone 'evac2': Suspending zone on source host.
zoneadm: zone 'evac2': Waiting for migration to complete.
zoneadm: zone 'evac2': Migration successful.
zoneadm: zone 'evac2': Halting and detaching zone on source host.

Since SRU 30, you can also use the same option when evacuating Zones, both ways, meaning both with and without the -r option. It's all or nothing at this point - meaning you can either overwrite all existing configurations on your targets, or none. Our customers were not really interested in a per-zone setting but we could provide that in the future if we got enough requests to enhance it that way.

For both the migration and evacuation, the -w and -n options are mutually exclusive, and that probably does not surprise you.

# sysadm evacuate -avwn
sysadm: -w and -n are mutually exclusive

Note that when overwriting a configuration on the target with the -w option, we first remove the config, then import the new one. That has an unfortunate consequence: if there is a configured zone evacuation target on the target host for that zone being migrated, it will be gone with the configuration removal as removing a zone configuration also removes its corresponding SMF system/zones/zone:<zonename> instance (see a blog entry on the Zones Delegated Restarter for more information).

The problem manifests as follows:

# sysadm evacuate -av
sysadm: preparing 3 zone(s) for evacuation ...
sysadm: initializing migration of evac2 to target-host ...
sysadm: initializing migration of evac1 to target-host ...
sysadm: initializing migration of s10 to target-host ...
sysadm: evacuating 3 zone(s) ...
sysadm: migrating evac1 to target-host ...
sysadm: migrating evac2 to target-host ...
sysadm: migrating s10 to target-host ...
sysadm: evacuation completed successfully.
sysadm: evac1: evacuated to ssh://target-host
sysadm: evac2: evacuated to ssh://target-host
sysadm: s10: evacuated to ssh://target-host
# sysadm evacuate -arw
sysadm: preparing zones for return ... 3/3
sysadm: returning zones ... 3/3
sysadm: return completed successfully.
# sysadm evacuate -av
sysadm: preparing 3 zone(s) for evacuation ...
sysadm: initialization failed
sysadm: evac1: initialization failed: evacuation/target not set for zone service svc:/system/zones/zone:evac1
sysadm: evac2: initialization failed: evacuation/target not set for zone service svc:/system/zones/zone:evac2
sysadm: s10: initialization failed: evacuation/target not set for zone service svc:/system/zones/zone:s10

To fix that, one has to set the evacuation targets again, as explained in the blog entry on the Zones evacuation.

This was an overlook in the implementation of the feature and already fixed internally but the fix is only planned to be released with SRU 33 (likely in May). Please beware of this if using the -w option with the evacuation until then.

And the last thing - what is gonna happen if you try to use the -w option on a target host running a system version before the feature was introduced (pre SRU 21)? It should behave the way you would expect - it fails with a clear error message:

# zoneadm -z evac2 migrate -w ssh://target-host
zoneadm: zone 'evac2': destination host does not support overwriting the zone configuration.

And similarly with the evacuation (the error about the s10 zone is due the fact that cold migration migration of solaris10 branded zones was also not supported in the initial 11.4 release):

# sysadm evacuate -avw
sysadm: preparing 3 zone(s) for evacuation ...
sysadm: initializing migration of evac1 to target-host ...
sysadm: initializing migration of s10 to target-host ...
sysadm: initializing migration of evac2 to target-host ...
sysadm: initialization failed
sysadm: evac1: planned evacuation to ssh://target-host failed: destination host does not support overwriting the zone configuration.
sysadm: evac2: planned evacuation to ssh://target-host failed: destination host does not support overwriting the zone configuration.
sysadm: s10: planned evacuation to ssh://target-host failed: solaris10 zone migration is unsupported

That is all about this new migrate -w option. Enjoy!

Join the discussion

Comments ( 1 )
  • jevgeniug Tuesday, February 16, 2021
    Finally! Is there any chance to get this option to Solaris cluster software?
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.