Migrating a zone between two global hosts

One feature of Solaris zones is the ability to migrate a non-global zone from one global host to another. In the case of zones built on zfs filesystems, this can be done as follows. (If you're using UFS, substitute tar commands for the zfs commands).

The rationale for this move is that the zone has an interface on VLAN101, but needs a second interface on VLAN102. The global host it is currently attached to (mars) does not have an interface on VLAN102. Another global host (venus) has interfaces on both VLANs, and is therefore an appropriate (in fact the only) candidate for receiving the zone.

Global1=mars
Global2=venus
zone=scorpio

First, let's check the Solaris 10 release level on each box.

(cat /etc/release)

mars: Solaris 10 10/08 s10s_u6wos_07b SPARC
venus: Solaris 10 10/09 s10s_u8wos_08a SPARC

And architecture:

(uname -m)

mars: sun4v
venus: sun4v



Moving from a lower release to a higher one will certainly involve some packages being upgraded, but Solaris will handle most of that automatically. Hopefully.



So, first, let's halt the zone and detach it:

mars# zoneadm -z scorpio halt
mars# zoneadm -z scorpio detach

The zone is now ready for transfer, which we will do with the convenient zfs commands available. If you are not using zfs, tar and ssh will work just as well.


First we'll take a snapshot of the zone filesystem:

mars# zfs snapshot -r rootpool/zones/scorpio@mars

We also have a zfs dataset allocated to the zone, so we'll snapshot that too:

mars# zfs snapshot -r datapool/zones/scorpio@mars

Just quickly check those snapshots have been taken:

mars# zfs list -t snapshot|grep scorpio
rootpool/zones/scorpio@mars
datapool/zones/scorpio@mars
datapool/zones/scorpio/zonedata@mars
datapool/zones/scorpio/zonedata/opt@mars

Great. Now for sending them. Firstly, we'll need to allow a root login (temporarily) on venus:

venus# vi /etc/ssh/sshd_config
change
PermitRootLogin no
to
PermitRootLogin yes
venus# svcadm restart ssh:default

let's send them:

mars# zfs send rootpool/zones/scorpio@mars | ssh root@venus "zfs recv rootpool/zones/scorpio"
Password:
mars# zfs send datapool/zones/scorpio/zonedata@mars | ssh root@venus "zfs recv rootpool/zones/scorpio/zonedata"
Password:
mars# zfs send datapool/zones/scorpio/zonedata/opt@mars | ssh root@venus "zfs recv rootpool/zones/scorpio/zonedata/opt"
Password:

Note that they're being received to the rootpool on venus, as it does not have a datapool configured.

Obviously now change the root login permission back to 'no':

venus# vi /etc/ssh/sshd_config
change
PermitRootLogin yes
to
PermitRootLogin no
venus# svcadm restart ssh:default

Now the datasets are transferred, we can attach the detached zone to the new global host. This is done with zonecfg, as with creating a new zone, but using create -a to specify that we are attaching a zone.

venus# zonecfg -z scorpio
scorpio: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:scorpio; create -a /zones/scorpio

Now let's check that has imported all the zone config:

zonecfg:scorpio; info
zonename: scorpio
zonepath: /zones/scorpio
brand: native
autoboot: true
bootargs:
pool:
limitpriv:
scheduling-class: FSS
ip-type: shared
[cpu-shares: 1]
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 10.278.28.35
physical: e1000g101001
defrouter not specified
capped-memory:
physical: 4G
[swap: 4G]
dataset:
name: datapool/zones/scorpio/zonedata
rctl:
name: zone.max-swap
value: (priv=privileged,limit=2147483648,action=deny)
rctl:
name: zone.cpu-shares
value: (priv=privileged,limit=1,action=none)

We'll need to make some changes here, as the zfs dataset is no longer part of datapool, but rootpool, because the interface on VLAN 101 is named differently on venus, and because we need the zone to have a new interface on VLAN 102.

Change interface name:

zonecfg:scorpio; select net address=10.278.28.35
zonecfg:scorpio:net; info
net:
address: 10.278.28.35
physical: e1000g101001
defrouter not specified
zonecfg:scorpio:net; set physical=aggr101001
zonecfg:scorpio:net; end

Add new interface:

zonecfg:scorpio; add net
zonecfg:scorpio:net; set address=10.278.38.35
zonecfg:scorpio:net; set physical=aggr102001
zonecfg:scorpio:net; end

Change dataset name:

zonecfg:scorpio:dataset; set dataset rootpool/zones/scorpio/zonedata/opt@mars
zonecfg:scorpio:dataset; set name=rootpool/zones/scorpio/zonedata/opt
zonecfg:scorpio:dataset; end

Commit these changes and exit:

zonecfg:scorpio; commit
zonecfg:scorpio; exit

The zone is now configured and ready to be attached. But (as we read in the zoneadm manpages):

By default, zoneadm checks package and patch levels on
the machine to which the zone is to be attached. If the
packages/patches that the zone depends on from the glo-
bal zone are different (have different revision numbers)
from the dependent packages/patches on the source
machine, zoneadm reports these conflicts and does not
perform the attach.

Adding a '-u' flag tells Solaris to attempt to upgrade any packages/patches at a lower version in the new zone, though it cannot downgrade packages/patches.

Running without '-u' gives you a long list of package and patch inconsistencies, as we are moving from update 6 to update 8.

root@venus# zoneadm -z scorpio attach -u
zoneadm: zone 'scorpio': ERROR: attempt to downgrade package SUNWlucfg, the source had patch 121430-43 but this system only has 121430-42
zoneadm: zone 'scorpio': ERROR: attempt to downgrade package SUNWlur, the source had patch 121430-43 but this system only has 121430-42
zoneadm: zone 'scorpio': ERROR: attempt to downgrade package SUNWluu, the source had patch 121430-43 but this system only has 121430-42
zoneadm: zone 'scorpio': ERROR: attempt to downgrade package SUNWservicetagr 1.1.4,REV=2008.04.25.09.06 to version 1.0,REV=2007.05.21.20.36
zoneadm: zone 'scorpio': ERROR: attempt to downgrade package SUNWservicetagu 1.1.4,REV=2008.04.25.09.06 to version 1.0,REV=2007.05.21.20.36
zoneadm: zone 'scorpio': ERROR: attempt to downgrade package SUNWstosreg 1.1.4,REV=2008.04.25.09.06 to version 1.0,REV=2007.05.21.20.36

Somewhere along the line, someone has upgraded these packages, and patch 121430 on the u6 box, and they are at a higher level on the zone than they are on the new target global_host.

If this happens to you, it's likely that you'll have a completely different set of patches and packages, and you should proceed accordingly. Here, the Services Tools Bundle has been installed, and the aforementioned patch 121430. I downloaded and applied these to venus.

# zoneadm -z scorpio attach -u
Getting the list of files to remove
Removing 326 files
Remove 24 of 24 packages
Installing 189 files
Add 15 of 15 packages
Updating editable files
The file within the zone contains a log of the zone update.

# zoneadm list -iv | grep scorpio
- scorpio installed /zones/scorpio native shared

# zoneadm -z scorpio boot
# zoneadm list -iv | grep scorpio
81 scorpio running /zones/scorpio native shared

Success!