Deploying HCL VersionVault on Solaris zones
If you intend to run HCL VersionVault on Solaris zones, there are some special considerations that affect how you deploy VersionVault.
About Solaris zones
Zone | Description |
---|---|
global zone | The global zone is the initial zone of the Solaris operating system. This zone has
full privileges; it is the zone that is running when the system is booted. The global zone can host three different types of non-global zones: regular, branded, and kernel zones. |
non-global zone | A non-global zone is a virtual machine that resides on top of the operating system,
with its own host name, IP address, set of file systems, and so on. It is dependent for some of its
resources on the global zone (non-global zones are sometimes referred to simply as
zones). A non-global zone provides namespace and process space isolation, as well as separation from the physical devices and network interface names. This isolation prevents processes in a non-global zone from monitoring or affecting either the global zone or another non-global zone. |
branded zone | A branded zone is a non-global zone that runs a version of the operating system that is different from the version running on the host. |
kernel zone | A kernel zone is another type of zone introduced in Solaris 11 update 2. A kernel zone does not share kernel resources with a global zone in the way that non-global zones and branded zones do. Instead, it has its own kernel and full operating system environment including device drivers and memory management. It functions independently of the global zone. |
nested zone | A nested zone is a non-global zone hosted within a kernel zone. Multiple nested zones can run simultaneously within a kernel zone. The kernel zone acts as the global zone for the nested zones and shares its resources with the nested zones. |
Refer to the Oracle product documentation for instructions on configuring and using Solaris zones.
Deployment requirements
- All zones on a host must run the same version of VersionVault at the same fix pack level.
- If you run branded zones, remember that VersionVault support for the branded zone's operating system can be different from VersionVault support for the global zone's operating system. Therefore, when installing or upgrading VersionVault, you must specify a version and fix pack of VersionVault that supports the operating systems on the global zone and the specific branded zone.
- If non-global zones are intended to support dynamic views, you must install the MVFS on the global zone.
- When you install VersionVault for the first time on a host, you must install it on the global zone before you install it on any non-global zones.
- Before upgrading VersionVault, you must stop instances of VersionVault that are running on the non-global zones. While these instances of VersionVault are stopped, you upgrade the global zone, and then you upgrade the non-global zones.
- When uninstalling VersionVault, you must uninstall it from the non-global zones before you uninstall it from the global zone.