InfoUnix

Linux · Solaris · DevOps

Solaris · Kernel Zones – Clone, Detach/Attach & Migration

Solaris · Zones · Advanced

Kernel Zones – Clone, Detach/Attach & Migration

After you know how to create and manage kernel zones, the next step is to clone them for testing, and move them between hosts for maintenance, DR and hardware refresh. This lesson focuses on cloning, detach/attach and the idea of migration for kernel zones.

Clone, detach/attach and migration – what’s the difference?

Clone

Create a copy of an existing kernel zone on the same host (new hostname/IP inside). Great for testing or staging.

Detach / Attach

Move a kernel zone from one host to another by detaching, replicating the dataset and attaching on target.

Migration

On supported platforms, move a running (or powered-off) kernel zone to another host, with pre-checks via dry-run.

Why do this?

Hardware refresh: move zones to new server.
DR / HA: have the same zone on a secondary host.
Testing: clone production-like zone for lab/testing.
Patching: test new SRU in cloned zone before prod.

Pre-requisites and planning

Before clone / detach / migrate

Zone must not be in the middle of an install/upgrade.
Have enough storage on target (clone or migration).
Ensure same or compatible CPU features between hosts (for migration).
Network/IP plan done for cloned zones (no duplication).
Backups or ZFS snapshots taken for safety.

Practical: clone, detach/attach and migration commands

1. Check existing kernel zones

Start by listing all zones and identifying kernel zones (brand solaris-kz).

terminal — kernel zone migration

solaris-lab

[root@hostA ~]# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND       IP
   0 global           running    /                              solaris     shared
   1 kz-app01         running    /system/zones/kz-app01         solaris-kz  excl
   - kz-test          installed  /system/zones/kz-test          solaris-kz  excl

2. Clone kernel zone on the same host

Cloning is useful for creating a copy of an existing zone (lab, testing, pre-change snapshot-style copy).

terminal — kernel zone migration

solaris-lab

# Syntax: zoneadm -z NEWZONE clone SOURCEZONE
 
[root@hostA ~]# zoneadm -z kz-app01-clone clone kz-app01
A ZFS clone of the zonepath has been created.
 
# Verify
[root@hostA ~]# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND       IP
   0 global           running    /                              solaris     shared
   1 kz-app01         running    /system/zones/kz-app01         solaris-kz  excl
   - kz-app01-clone   installed  /system/zones/kz-app01-clone   solaris-kz  excl
 
# Boot the clone
[root@hostA ~]# zoneadm -z kz-app01-clone boot
 
[root@hostA ~]# zlogin -C kz-app01-clone
# Change hostname, IP, etc. inside the clone as needed.

3. Detach kernel zone before moving to another host

Detach marks the zone as exported; you then replicate the zone dataset to the target host (e.g. via ZFS send/receive).

terminal — kernel zone migration

solaris-lab

[root@hostA ~]# zoneadm -z kz-app01 halt
 
[root@hostA ~]# zoneadm -z kz-app01 detach
Zone 'kz-app01' is now detached.
 
# Now replicate the underlying ZFS dataset (example, actual pool/dataset may differ):
[root@hostA ~]# zfs list | grep kz-app01
rpool/system/zones/kz-app01      10G   100G   10G  /system/zones/kz-app01
 
# Send to remote host (simplified example)
[root@hostA ~]# zfs send rpool/system/zones/kz-app01@snap-move |                    ssh root@hostB zfs receive rpool/system/zones/kz-app01

4. Attach kernel zone on target host

After the dataset is available on target host, attach the zone there.

terminal — kernel zone migration

solaris-lab

# On hostB:
 
[root@hostB ~]# zonecfg -z kz-app01
zonecfg:kz-app01> create -a /system/zones/kz-app01
zonecfg:kz-app01> exit
 
# Attach and verify (zonepath already has the dataset)
[root@hostB ~]# zoneadm -z kz-app01 attach -F
Zone 'kz-app01' attached.
 
[root@hostB ~]# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND       IP
   0 global           running    /                              solaris     shared
   - kz-app01         installed  /system/zones/kz-app01         solaris-kz  excl
 
# Boot on hostB
[root@hostB ~]# zoneadm -z kz-app01 boot

5. Dry-run kernel zone migration (conceptual)

On platforms that support live migration, you can dry-run migrate to validate compatibility before moving.

terminal — kernel zone migration

solaris-lab

# Dry-run migration (syntax can vary by SRU; example only):
[root@hostA ~]# zoneadm -z kz-app01 migrate -n hostB
 
# If checks pass, run actual migration (may do live or cold depending on config):
[root@hostA ~]# zoneadm -z kz-app01 migrate hostB
 
# Always refer to 'man zoneadm' for your exact Solaris version for options.

Safety notes for kernel zone clone/migration

Never have the same zone identity (hostname/IP/app config) live in two places in production networks.
For detach/attach across hosts, make sure SRU levels are supported for that combination (check release notes).
Always validate after attach/migrate: boot, network, storage mounts, application start.
For live migration, test small non-critical zones first before trying big production workloads.

Once you understand clone and detach/attach, migration is mostly about automating the move and adding pre-checks.