Troubleshooting
Problem
This contains the WebSphere MQ support position regarding Solaris "zones".
Cause
Resolving The Problem
What are Solaris 10 zone and container technology?
The Solaris 10 OS offers Solaris Containers. This is a set of technologies that allows system administrators to create separate operating environments on the same system. This is to isolate and protect applications from each other, while allowing system utilization to increase. Solaris 10 Containers comprise two technologies: Solaris Zones partitioning technology and Resource Management. Solaris Zones provide virtualized operating environments that have their own hostname, IP address(es), users, file systems, and so on, while giving applications isolation and protection from each other. Resource Management controls how system resources are spread across specified workloads.
Solaris Zones partitioning technology provides virtualized and secure operating environments for running applications. Every Solaris system contains a global zone, which is comparable to a normal Solaris OS instance. Non-global zones can be created on the system from the global zone by the global zone administrator to create virtualized operating environments on the system that are isolated, and secure from each other.
More information can be found at:
http://www.sun.com/bigadmin/features/articles/basics_containers.html#Overview
Background to problems with WebSphere MQ
WebSphere MQ installs to the /opt file system and adds soft-links, message catalogs and man pages to the /usr file system. As a result, WebSphere MQ must be installed into an environment where /opt and /usr are writable. This can be done by installing into the global zone, or into a non-global zone with a local copy of /opt and /usr.
APAR IY80793 documents a change to the Solaris Quick Beginnings Guide. This explains the need for WebSphere MQ installers to write to the /usr file system.
When installed into the global zone, by default WebSphere MQ can only be used from the global zone. Note that when WebSphere MQ is installed into the global zone, a separate installation of WebSphere MQ will not be made into non-global zones. This is because the mqm package contains a "request script" (used to provide the menu that allows selection of which parts to install). The man pages for zoneadm and pkgadd state that "Any package that contains a request script is added to the global zone only".
GSKit does not use request scripts, and so if installed into the global zone will also be installed into all non-global zones. This can be avoided by using 'pkgadd -G', which will install it (like WebSphere MQ) into the global zone only. Note that this is only possible if there are no pre-existing non-global Sparse Root zones. (In other words, it is only possible for GSKit to install files into /usr for use only by the global zone when no other non-global zones are already sharing the /usr directory).
WebSphere MQ support position
Installation of WebSphere MQ is supported in zone environments as outlined below.
Approach: Installing into all Zones
Overview
On systems with multiple non-global zones, Solaris allows an install into all non-global 'whole root' zones at once.
Work required
Problem 1: This is not possible with WebSphere MQ. The Solaris installer, pkgadd, is not able to install into all zones for packages which include a 'request script'. The WebSphere MQ package uses a request script to provide the options menu displayed at install time.
Workaround: Install into each non-global zone manually. When installing in the global zone, use 'pkgadd -G' so that installing into all zones is not attempted.
Approach: Installing WMQ into the Global Zone
Overview
This is the closest approach to the existing install.
Work required
Problem 1: Inconsistent behavior when installing into Global Zone. By default, when installing into the global zone, software is also installed into all non-global 'whole root' zones. This is not possible with WebSphere MQ (because the WMQ installer uses 'request scripts'). As a result, WebSphere MQ is installed in the global zone only, while GSKit is installed into global zone and all non-global 'whole root' zones.
Workaround: To ensure consistent behavior for both WebSphere MQ and GSkit (that is, to install into global zone only), use 'pkgadd -G'.
Approach: Installing WMQ into the Global Zone and using in non-global 'Sparse Root' zones
Overview
The principle here is to have one instance of your executables (/opt/mqm) which is visible to all non-global sparse root zones. Each non-global zone would have it's own /var/mqm and so it's own queue managers. With each zone having it's own IP address, which essentially gives you the appearance of multiple machines with WMQ, but all sharing the same installed executables.
Work required
Problem 1: Installing into the Global Zone does not create the necessary /var/mqm structure in non-global zones.
Workaround: The /var/mqm directory structure can be copied from the global zone to a non-global zone. Note that the security permissions will need to be carefully checked to ensure that they are copied correctly. Queue manager data files (contents of /var/mqm/qmgrs, with the exception of /var/mqm/qmgrs/@SYSTEM) should not be copied - having multiple copies of the same queue manager running in different zones should not be attempted.
Problem 2: The installer ensures that an 'mqm' user and 'mqm' group are created. As the installer is not being run in the non-global zones, these user and group ids are missing.
Workaround: An mqm user and group should be manually created in each non-global zone, and these used in security permission settings for /var/mqm/ files and directories in the zone.
Approach: Installing WMQ into a non-global 'Whole Root' zone
Overview
This is the most straight-forward non-global zone option. It allows WMQ to be used from within the zone, but puts nothing into the global zone that would cause it to visible outside of the zone in which it is installed. Installs in different zones would not share anything.
It is unappealing in some ways because it requires such a large zone - the default (having only a subset of the root) is to have much smaller zones.
Work required
Problem 1: The WebSphere MQ post install script attempts to verify if kernel parameters are set correctly. Commands used to do this are not available within non-global zones, and fail with error messages displayed at install-time
## Executing postinstall script.
Insufficient privileges to load a module
Insufficient privileges to load a module
Insufficient privileges to load a module
Workaround: These error messages can be ignored. This occurs post-install, and does not effect the install itself. Kernel parameters should be verified manually using guidance available in the WMQ v6.0 product README file.
Approach: Installing WMQ into a non-global 'Sparse Root' zone
Overview
Note 1: On a system where WebSphere MQ is already installed in the global zone (when the non-global zone is created).
Note 2: Assuming a default zone configuration - therefore one without it's own copy of /usr.
When running the installer in the non-global zone, the files that pkgadd is normally unable to create (files in /usr) are already present due to the installation in the global zone. As a result, pkgadd just verifies that the properties are okay and continues, allowing the installation to complete successfully.
Work required
Problem 1: If WebSphere MQ is uninstalled from the global zone, the non-global zone installation will stop working (Attempts to run WMQ commands fail, displaying error messages reporting that WMQ is unable to open message catalog.)
Workaround: None.
Problem 2: As files in /usr are shared between the different installations, installing different versions of WebSphere MQ in the global and non-global zones will fail, as the files will not be consistent.
Workaround: None.
Problem 3: Attempts to uninstall from non-global zone fail to complete, as access is denied when it tries to remove files from /usr. The non-global zone installation remains in a 'partially installed' state.
Workaround: Retry uninstall to remove entry from package list. Files in /usr will remain untouched.
Approach: Installing WMQ into a custom zone configuration
Overview
Installing into a custom zone configuration - based on a Sparse Root approach but including a local copy of /usr.
This is configured in zonecfg using: remove inherit-pkg-dir dir=/usr
Work required
Problem 1: The WebSphere MQ post install script attempts to verify if kernel parameters are set correctly. Commands used to do this are not available within non-global zones, and fail with error messages displayed at install-time
## Executing postinstall script.
Insufficient privileges to load a module
Insufficient privileges to load a module
Insufficient privileges to load a module
Workaround: These error messages can be ignored. This occurs post-install, and does not effect the install itself. Kernel parameters should be verified manually using guidance available in the WMQ v6.0 product README file.
Support for other zones configurations
Other zones configurations are possible, for example installing WMQ into a sparse root zone when WMQ is not installed in the global zone. A successful install of WMQ into these configurations is likely to be more difficult to achieve than the configurations described here.
We do not provide supported instructions for achieving an install into configurations other than those described here.
However, we do support a successfully installed WMQ into other zones configurations, provided that the configuration itself is not causing the problem for which support is requested.
Useful Solaris document link:
http://www.sun.com/bigadmin/features/articles/basics_containers.html#installation
Refer to the WebSphere MQ Information Center for your version of WMQ to see applicable updates to the information in this technotes.
Product Synonym
WMQ WebSphere MQ
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21233258