Resource Pools for Solaris Zones Managed in Resource Orchestrator
In Resource Orchestrator, resource management is performed with one resource pool for a Solaris Zone being managed in each global zone.
The target resource pool can be changed.
For details, refer to "C.7.1 Creating Definition Files".
Non-Global Zone Names in Solaris Zones
When specifying the names of non-global zones managed by Resource Orchestrator, ensure that those names are unique.
When managing multiple non-global zones with the same names as L-Servers, do not manage only some of those non-global zones as L-Servers. Either manage all or none of such non-global zones as L-Servers.
When there are multiple non-global zones with the same name, if only some of them are managed as L-Servers, those zones may be erroneously recognized as the same non-global zone.
Operations when uuids Change in Solaris Zones
In Resource Orchestrator, manage the non-global zone using uuids.
As a Solaris Zone configures a uuid for each OS, when the OS is reinstalled in a non-global zone or when the global zone on which a non-global zone is started is changed, the uuid of the non-global zone changes. When a uuid changes, the operation varies depending on whether the zone is managed as an L-Server.
When the non-global zone is not being managed as an L-Server
If an operation that leads to uuid change is performed, the non-global zone with the changed uuid will be recognized as a new non-global zone. As a result, the label, comment, and home position setting which were configured for the non-global zone will be cleared. Reconfigure those settings.
When the non-global zone is being managed as an L-Server
If an operation that leads to uuid change is performed, when the non-global zone with the changed uuid is detected, whether the non-global zone is the same or not is determined based on the non-global zone name. If the zone is determined to be the same, settings which had been configured for that zone before the uuid changed will be inherited.
If the zone is determined to be different, such as when there are multiple non-global zones with the same name, that zone will be recognized as a new non-global zone. In that case, it is necessary to associate the zone with the L-Server and import it into the L-Platform again.
Release the L-Server from the L-Platform and delete the L-Server, then associate the server with the L-Server and import the L-Server to the L-Platform.
For details about releasing the L-Server from the L-Platform, refer to "7.2.3.3 Releasing L-Servers" in the "Operation Guide CE".
For details about deleting the L-Server, refer to "17.4 Deleting an L-Server" in the "User's Guide for Infrastructure Administrators (Resource Management) CE".
For details about importing the L-Server to the L-Platform, refer to "7.2.3 Importing to L-Platform" in the "Operation Guide CE".
Migration Operations
Resource Orchestrator provides a function which migrates non-global zones between global zones (cold migration only). This function is realized by performing the following procedure.
The non-global zone to migrate is stopped.
The servers at the migration source and destination have the same system environment.
Detach the non-global zone at the migration source.
Do this using zoneadm detach.
In the global zone at the migration source, unmount the disk which is mounted on the zone path of the non-global zone.
In the global zone at the migration destination, mount the disk on the zone path to be used by the non-global zone, according to the definition in vfstab.
The zone path used for the non-global zone is configured according to the definition of the registered disk resource.
In the global zone at the migration destination, create a non-global zone.
In the global zone at the migration destination, attach the non-global zone.
Here, perform this using zoneadm attach with the -u option specified.
It is not recommended to perform normal operations while carrying out migration, for the following reasons. Consider the risks before performing migration.
If the disk resources or global zones are incorrectly configured, Resource Orchestrator will try to attach the non-global zone using an incorrect disk at the destination server. As a result, the data in the non-global zone may be corrupted or the non-global zone may disappear.
If a migration operation fails, the zone will not be automatically rolled back to the state before the operation.
In that case, log in to the global zones at the migration source and destination and perform recovery.
When doing this, be sure to recover the migration destination first. If you recover the migration source first, the disk will be accessed from both global zones, which may corrupt the data.
CPU Performance and the Number of CPUs for L-Servers
Update the CPU performance and the number of CPUS, using the values calculated by the cap values, when the CPU performance and the number of CPUs for L-Servers are different from the values calculated from the cap values configured in the non-global zone.
When the cap values calculated using the CPU performance and the number of CPUs for L-Servers are the same as those configured for the non-global zone, the CPU performance and the number of CPUs for L-Servers are not updated, and the values are not changed from the configured values.
CPU Performance and the Number of CPUs for L-Servers when Changing cap Values in the Non-global Zone
When increasing the cap value in the non-global zone, the CPU performance for L-Servers may be the same as the value before changing of the cap value, not the CPU performance calculated by the cap value.
If this occurs, increase the cap value by one. After checking if the CPU performance for L-Servers has changed, change the cap value to the intended value.
Changing L-Server Specifications
If the CPU performance is increased by 0.1 GHz when modifying L-Server specifications, but the number of CPUs is not changed, the cap values in the non-global zone may not have been changed.
To change the cap values for certain, change the value by 0.2 GHz or more.
LUNs Shared between Multiple Global Zones
Do not mount LUNs that are shared between multiple global zones or the LUNs for the zone path used by virtual L-Servers by selecting them from the other global zone. Data may be damaged when deploying the virtual L-Server using the disk for the corresponding LUN, due to conflicting LUN access.
Non-global Zone Charges
The following settings need to be made when creating the non-global zone if the non-global zone's CPU or memory will be using the metering and usage fee functions.
However, these settings are not necessary if metering and usage fee functions are not used, or if the CPU or memory are not made the subject of charges.
Subject of charges | Required settings |
|---|---|
CPU | Perform CPU sharing settings |
Memory | Perform memory capping settings |
Refer to the documentation that that comes with the Operating System for information on CPU sharing and memory capping.
