Creating and Using Oracle Solaris Kernel Zones

Exit Print View

Updated: December 2014

Kernel Zone Host Data and Host ID

Each kernel zone bootable device contains state information known as host data. A kernel zone's host data monitors kernel zone state information including:

  • Zone usage

  • Zone suspends, as described in Suspending and Resuming a Kernel Zone

  • Time of day offset between the kernel zone clock and the global zone clock

  • OpenBoot variables (SPARC only)

Kernel zone host data is encrypted and authenticated with the advanced encryption standard AES-128-CCM, using the same encryption key used for the kernel zone suspend image.

When a kernel zone is configured or booted, the host data is read to determine whether the kernel zone's boot storage is in use on another system. If the boot storage is in use on another system, the kernel zone will enter the unavailable state and an error message will indicate which system is using the boot storage. For example:

global# zoneadm -z kzone1 attach
zone 'kzone1': error: ERROR: zone kzone1 is in use by host with  hostid 848611d4
zone 'kzone1': error:       last known state: installed
zone 'kzone1': error:               hostname: global2
zone 'kzone1': error:  boot environment name: solaris-1
zone 'kzone1': error:  boot environment uuid: 69ed2e6a-e25a-6d36-e022-ed7261ed8899
zone 'kzone1': error:       last update time: Sun Apr 13 20:08:13 2014
zone 'kzone1': error: To fix, detach the zone from the other host then attach it to this host
zone 'kzone1': error: If the zone is not active on another host, attach it with
zone 'kzone1': error:    zoneadm -z kzone1 attach -x force-takeover

If the boot storage is not in use by the other system, you can repair the kernel zone by using the zoneadm attach -x force-takeover command.


Caution  -  Forcing a takeover or reinitialization of the host data makes it impossible to detect if the zone is in use on any other system. Running multiple instances of a zone that reference the same storage leads to unrepairable corruption of the zone's file systems.

If a zone's encryption key is not accessible, the host data and any suspend image will not be readable. In such circumstances, any attempt to ready or boot the zone will cause the zone to enter the unavailable state. If recovery of the zone's encryption key is not possible, use the zoneadm attach -x initialize-hostdata command to generate a new encryption key and host data.

To prevent loss of the encryption key during a kernel zone migration, use the zonecfg export command on the source system to generate a command file to be used on the destination system. For example:

global# zonecfg -z kzone1 export -f /net/.../kzone1.cfg
global# zonecfg -z kzone1 -f /net/.../kzone1.cfg