solaris10 - Solaris 10 branded zone
The solaris10 brand uses the branded zones framework described in brands(7) to enable Solaris 10 binary applications to run unmodified on a machine with the latest Solaris Operating System kernel.
Oracle Solaris 10 Zones are solaris10 branded zones that host x86 and SPARC Solaris 10 9/10 (or later released Oracle Solaris 10 update) user environments running on the Oracle Solaris 11 kernel.
Note that it is possible to use an earlier Oracle Solaris 10 release if you first install the kernel patch 142909-17 (SPARC) or 142910-17 (x86/x64), or later version, on the original system. Alternatively, the –P option to the install subcommand can be used to apply required patches if those patches are missing in zone's image.
The solaris10 brand includes the tools necessary to install a Solaris 10 system image into a non-global zone. It also supports the tools necessary to migrate a Solaris 10 native zone to a solaris10 branded zone. The brand supports the execution of 32-bit and 64-bit Solaris 10 applications on either SPARC or x86 machines running the latest Solaris operating system.
The solaris10 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 zonecfg(8) utility is used to configure a solaris10 branded zone. The SYSsolaris10 template can be used when creating the zone or the configuration can be set up manually. Once a branded zone has been installed, that zone's brand cannot be changed or removed. The zoneadm(8) utility is used to report the zone's brand type and administer the zone. The zlogin(1) utility is used to log in to the zone.
The following zonecfg(8) resources and properties are not supported by the solaris10 brand:
autoshutdown=suspend anet:evs anet:vport anet:id device:id file-mac-profile net:id tenant virtual-cpu anet:mac ib-vhca ib-vhca:port capped-memory:pagesize capped-memory:pagesize-policy
The following zoneadm(8) resources and properties are supported by the live zone reconfiguration for solaris10 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 zoneadm(8) resources and properties are not supported by the live zone reconfiguration for solaris10 brand:
anet:allowed-address anet:configure-allowed-address anet:defrouter fs-allowed hostid limitpriv global-time net:allowed-address net:configure-allowed-address net:defrouter npiv 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.
When migrating from Solaris 10, it is possible that the zone is configured as a sparseroot zone. In this case, the zone should be readied (zoneadm ready) on the host before the archive is made. This ensures that the inherited directories are included in the archive.
There are specific defaults for properties supported for solaris10 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 ZFS dataset com.oracle.zones.solaris10:activebe user property exists to support multiple boot environments for Solaris 10 branded zones. To activate a boot environment, the user has to set the com.oracle.zones.solaris10:activebe property on the zone's ROOT dataset as shown below:
# zfs set com.oracle.zones.solaris10:activebe=zone-ROOT-dataset-BE-name
An installed Solaris 10 zone with more than one boot environment is required to have the activebe property set. If the property is not set, or is set to a missing or invalid boot environment name, the zone will transition to unavailable state on next zone or system boot. To resolve this, the activebe property must be corrected, and the zone must be attached with zoneadm attach. For more information, see examples 4 and 5.
Oracle Solaris 11.4 introduces the PF firewall, to replace the IPFilter network firewall (legacy firewall). See the firewall(7) man page.
If your solaris10 branded zone uses the legacy firewall, the legacy configuration data remains intact in the /etc/ipf directory.
The first time you boot a solaris10 branded zone on Oracle Solaris 11.4, the zone boot process creates pf.conf configuration file in the /etc/firewall directory. The transition process does not attempt to convert the legacy firewall configuration to use the PF firewall rules. The initial pf.conf configuration file is made syntactically invalid to force the firewall service into the maintenance state. After you add the rules that you want to the pf.conf file, remove the delete-me line. For information about using the pf.conf file to configure the PF firewall, see the pf.conf(7) man page.
The first boot of a solaris10 zone also updates the legacy svc:/network/ipfilter service to use the PF firewall. From within the zone, the svc:/network/ipfilter SMF service manages the PF firewall.
The PF firewall uses “capture links” to log packets on behalf of log action in firewall rule. See the dladm(8) man page. When booted, a solaris10 branded zone creates a default pflog0 capture link for packet logging. Each time you halt or shut down the zone, the pflog0 link is destroyed. Note that you can access the capture link only from within a global zone and not from within the solaris10 branded zone itself.
To save packets that are logged by a solaris10 branded zone, you must configure and enable the pflogd service instance in the global zone. The following example shows how to configure and enable the pflogd service for the zone1 solaris10 branded zone:
global$ pflogd -C zone1 -i zone1/pflog0 -f /var/log/firewall/zone1.pkt global$ svcadm enable svc:/network/firewall/pflog:s10
solaris10 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 default for most userland security extensions is "model=tagged-files", and since Solaris 10 has no tagged files (and ignores tags on files even if they have them) this doesn't create a problem for most programs.
The exception is nxstack. The default for the nxstack sec extension is "model=all", and that does create a problem for a Solaris 10 program that generates executable code on the stack and then branches to it.
To allow legacy applications requiring exacutable stack to function the same way as in the native Solaris 10 environment, a SMF service svc:/system/security/executable-stack is provided.
To disable non-executable stack security extension for the zone it is sufficient to enable the executable-stack.
Since majority of applications work fine with the non-executable stack protection enabled, the service is disabled by default.
For the list of solaris10 brand-specific subcommand options, see zoneadm(8).
The following example shows how to create an archive for a physical to virtual (P2V) migration. This is performed in the global zone of a system that is running Solaris 10. The Solaris 10 system must not have any non-global zones configured, installed, or running. The Solaris 10 system can use ZFS or UFS as its root file system.
# flarcreate -n s10box -c /net/somehost/p2v/s10box.flarExample 2 Installing a solaris10 Branded Zone Using a Flash Archive
The following example installs a zone using the archive from Example 1. It assumes the zone has already been configured with zonecfg(8) and has the brand property set to solaris10.
# zoneadm -z s10p2v install -a /net/somehost/p2v/s10box.flar -pExample 3 Creating a ZFS Archive for Install
The following example shows how to create an archive for a virtual to virtual (V2V) migration. It assumes that the zonepath for the solaris10 branded zone is /zones/v2vzone.
First, determine the name of zonepath dataset.
# dataset=$(zfs list -H -o name /zones/v2vzone)
Next, create a snapshot of the zone's datasets.
# zfs snapshot -r $dataset@v2v
Finally, generate a ZFS self-contained recursive stream that is compressed with bzip2.
# zfs send -rc $dataset@v2v | bzip2 > /net/somehost/v2v/v2v.zfs.bz2Example 4 Installing a Zone Using a ZFS Archive
The following example installs a zone using a ZFS archive. It assumes that the zone has already been configured using zonecfg(8) and that the brand property is set to solaris10.
# zoneadm -z v2vzone install -a /net/somehost/v2v/v2v.zfs.bz2Example 5 Setting the Zone's Active Boot Environment From the Global Zone
# zfs set com.oracle.zones.solaris10:activebe=zbe-1 \
rpool/export/zones/branded_zones/S10_zone/rpool/ROOT
Example 6 Creating a New Boot Environment From a Solaris10 Branded Zone
The following example creates a new boot environment From a solaris10 branded zone. The example also shows how to patch, activate, and boot to the new boot environment.
Create a new boot environment.
# zfs snapshot rpool/ROOT/zbe-0@snap
# zfs clone -o mountpoint=/ -o canmount=noauto \
rpool/ROOT/zbe-0@snap rpool/ROOT/zbe-1
# zfs promote rpool/ROOT/zbe-1
Patch the boot environment.
# zfs mount -o mountpoint=/mnt rpool/ROOT/zbe-1 # patchadd -R /mnt -d /var/tmp/999999-01 # zfs unmount rpool/ROOT/zbe-1
Activate the new boot environment and boot to it.
# zfs set com.oracle.zones.solaris10:activebe=zbe-1 \
rpool/ROOT
# shutdown -y -g 0 -r
The following example installs a zone from an archive taken from an earlier Solaris 10 release. It will make the target zone ready to boot by applying the Recommended OS Patchset.
Unzip a Recommended OS Patchset
# unzip -q 10_Recommended_CPU_2018-07.zip
Install zone using older Solaris 10 archive
# zoneadm -z s10z install -u -a /net/somehost/s10u5.flar \
-P `pwd`/10_Recommanded_CPU_2018_07
To disable the NXSTACK security extension in given zone at boot it is sufficient to enable the executable-stack service
# svcadm enable executable-stack
See attributes(7) for a description of the following attributes:
|
zlogin(1), zonename(1), attributes(7), brands(7), firewall(7), pf.conf(7), solaris-kz(7), zones(7), archiveadm(8), dladm(8), zfs(8), zoneadm(8), zonecfg(8)
This feature might be removed in a future release of Oracle Solaris.