solaris - solaris branded zone
The solaris brand uses the branded zones framework described in brands(7) to run zones installed with the same software as is installed in the global zone. The system software must always be in sync with the global zone when using a solaris brand. The system software packages within the zone are managed using the image packaging system.
The solaris brand supports the whole root non-global zone model. All of the required system software and any additional packages are installed into the private file systems of the zone. The zone must reside on its own zfs(8) dataset and only ZFS is supported. The ZFS dataset is created automatically when the zone is installed or attached. If a ZFS dataset cannot be created, the zone is not installed or attached.
The following zonecfg(8) resources and properties are not supported by the solaris brand:
autoshutdown=suspend anet:id device:id net:id virtual-cpu anet:mac ib-vhca ib-vhca:port capped-memory:pagesize capped-memory:pagesize-policy
There are specific defaults for properties supported for solaris brand as listed below:
Resource Property Default Value
global zonepath /system/zones/%{zonename}
autoboot false
global-time false
ip-type exclusive
auto-shutdown shutdown
net configure-allowed-address true
anet mac-address auto
lower-link auto
link-protection mac-nospoof
The following zonecfg(8) resources and properties are supported by the live zone reconfiguration for solaris brand:
anet (with exceptions stated below) capped-memory dedicated-cpu device fs net (with exceptions stated below) pool scheduling-class zone.* rctls dataset
The following zonecfg(8) resources and properties are not supported by the live zone reconfiguration for solaris brand:
anet:allowed-address anet:configure-allowed-address anet:defrouter anet:evs anet:vport file-mac-profile fs-allowed hostid limitpriv global-time net:allowed-address net:configure-allowed-address net:defrouter npiv rootzpool tenant zpool
Any changes made to the listed unsupported resources and properties in the persistent configuration will be ignored by the live zone reconfiguration if they are applied to the running zone.
Any attempts to modify the listed unsupported resources and properties in the live configuration will be refused.
For the list of solaris brand-specific subcommand options, see zoneadm(8).
solaris branded zones can be cold migrated to compatible hosts by using the zoneadm migrate command, as described in the zoneadm(8) man page.
For cold migration to work, the same services and packages must be configured as for the solaris-kz(7) brand cold migration.
Only zones on shared storage may be migrated. Supported storage URI types for migration are iscsi and lu.
The following auxiliary state (as shown by zoneadm list -is) is defined for this brand:
The zone is known to the system but its configuration is missing. State of the zone is always incomplete.
The following example shows how to create an archive of a global zone, then use that archive to configure and install a non-global zone. The installation process transforms the image of a global zone such that it can work as a non-global zone. This process is commonly referred to as P2V (physical to virtual).
To ensure that the data in the archive does not become stale, applications running in the source zone should be stopped or the zone itself should be shut down before the archive is created. If neither of these is done, it may become necessary to synchronize application data after the zone is installed.
First, create a recovery archive of the source system. This assumes the source system has no non-global zones installed.
web-1# archiveadm create --recovery /net/images/web-1.uar
Next, configure the zone on the target system using the configuration stored in the archive. It may be necessary to further customize it. See examples in zonecfg(8).
t4-1# zonecfg -z web-1 Use 'create' to begin configuring a new zone. zonecfg:web-1> create -a /net/images/web-1.uar zonecfg:web-1> set zonepath=/zones/web-1 zonecfg:web-1> exit
If there is a preference for not using the interactive mode, you can use the following command:
t4-1# zonecfg -z web-1 "create -a /net/images/web-1.uar; \
set zonepath=/zones/web-1"
Finally, install the zone from the archive.
t4-1# zoneadm -z web-1 install -a /net/images/web-1.uar
If both the source system and newly installed zone have the same IP address or have other potential conflicts, be sure that only one of them is running at a time.
Example 2 Zone Migration Using a Unified ArchiveTo ensure that the data in the archive does not become stale, it is suggested that applications on the source zone are stopped or the zone is shut down before creating the archive. If this is not done, it may be necessary to synchronize application data after the zone is installed.
First, create a recovery archive of the zone. This is best performed from the global zone. If it is performed within the zone, the zone will not be able to be configured from the archive.
t4-1# archiveadm create -r -z web-1 /net/images/v2v/web-1.uar
Next, configure the zone on the target system using the archive.
t4-2# zonecfg -z web-1 create -a /net/images/v2v/web-1.uar
Finally, install the zone from the archive.
t4-2# zoneadm -z web-1 install -a /net/images/v2v/web-1.uar
Be sure to shutdown the zone on the source system before booting it on the target system.
See attributes(7) for a description of the following attributes:
|
archiveadm(8), brands(7), zfs(8), zoneadm(8), zonecfg(8), zones(7)