Skip to Content
Releasing Solaris 10 Sun introduced a new concept for OS based virtualization, called Solaris Zones. A Zone is a virtual instance of a (Solaris) guest operating system within a (Solaris) host system. The concept is pretty similar to BSD Jails or Linux VServer and comparable to an extended chroot environment: the guest operating systems share the same kernel and drivers but run within an isolated environment containing an individual directory structure, user management and so on. All guest systems (also referred to as “local” zones) are accessible from the “global zone” which is the host system. Within the local zone neither other zones nor the host system is accessible or even viewable. This way a lot of independent OS environments can be created and hosted within one physical server hardware.   h3. Why installing SAP in a virtual environment? Well, of course the benefits of installing applications in virtualized environments depend on the business case. Anyway, in general there are some general advantages which should be valid for the most scenarios including ** Increasing system stability and security using isolation of different systems, e.g. separating a database server from the SAP application server using different zones ** ** Lower costs for computing centers/ administration ** ** Higher Flexibility ** ** New ways for Backups, Tests, Maintenance, Upgrades, Patches etc. ** Of course there are various other reasons. You may want to read further resources for more information take a look at[1].   h3. Why not installing SAP in virtual environments? Where’s light, there’s shadow. Of course there are some (big) disadvantages when using virtualization techniques. Here are some of them: 0.1. 0.2. Performance loss caused by virtualization (up to ~40% depending on the type and the implementation of the virtualization solution) 0.3. Additional knowledge, configuration and administration is required 0.4. 0.5. Virtualization software may cause unpredictable errors 0.6. 0.7. Host system is a potential single point of failure (SPOF) for all hosted systems 0.8. 0.9. restricted support by SAP (e.g. Note 674851) 0.10.   h3. Why installing SAP in Solaris Zones? Of course the Solaris Zones solution is just one way of implementing virtualization concepts. There are various implementations on the market which could be used and they all have their special benefits and disadvantages. One simple answer why one would choose to use Solaris Zones could be: It’s a supported environment. That’s important due to SAP does not support all virtualization types and products in general at the moment. Therefore you might risk the support for your SAP system when installing it in an unsupported environment. Anyway, a much more practical reason is: Zones are pretty easy to use! And they are included in every Solaris 10 distribution by default. Here are some other pros and cons for installing a SAP system within a Zone: (+) Resource Management available (Solaris Containers (2) – CPU, network consumption and Memory consumption can be limited explicitly) (+) Proven OS technology with easy administration tools (+) Low overhead (Sun official statement: ~3% workload for virtualization) (+) New Zettabyte file system (ZFS) with many features including Snapshot, Clones, build-in logical volume management etc. (+) Inter-machine transport available (3) (+) Very cost efficient (-) Only Solaris as host operating system and guest operating systems is supported (-) Zone-specific kernel changes not available (-) Not applicable with every application and service (e.g. NFS) (-) I/O cannot be limited via resource pooling   h3. How to do it Setting up a new zone is pretty easy. However, I don’t want to explain zone creation in detail (because there are already various resources available which do that much better then I could (4)). But I want to give a quick overview about the zone creation and administration tools to provide a first impression how to handle with zones h4. Tools +zonecfg+ +zoneadm+ This command is used for central zone administration including starting, stopping, and (un)installing a zone. “zoneadm” is only available in the global zone. +zlogin+ Using zloging you can login to local zones from the global zone. Usually the syntax of using it should be similar to “zlogin -C -e\@. my_zone_name” where “@.” is the escape character. When you want to log out from a zone, use exit until you prompted for your user credentials. Then press “@.” to get back to the global zone. Note: After installing a network you may configure additional access to the zone, e.g. via secure shell or remote login. +zonename+ To get the name of the current zone the “zonename” command is used. For example, the name of the global zone is always “global”. It is available in all zones.   h2. Steps to create a zone: Example It is pretty easy to create a new zone from scratch and should be done in a few minutes:   +Creating a new zone:+ zonecfg -z my_new_zone create This will open the zone configuration tool. Here you can specify the path to the zone, network settings etc. The tool creates a kind of template for a new zone which is stored within an xml file. Therefore you may reuse it later. +Installing the zone+ Once a zone is created, you have to install the zone before using it. This may take a while. zoneadm -z my_new_zone install To uninstall the zone, use the parameter “uninstall” instead of install. This will erase everything installed within the zone including the file system structure +Booting the zone+ zoneadm -z my_new_zone boot +Logon to the zone+ zlogin -C -e\@. my_new_zone Now you can login to the zone. The configuration wizards (as after a “normal” solaris installation) will appear and ask you for passwords, network settings and so on.   h3. Known Issues The setup of SAP within a zone is pretty much the same as setting up the system within a regular Solaris environment. But some zone limitations may require workarounds. h4. Read-Only directories +Please read Wolfgang Pungartnik’s comment regarding read-only directories!+ The /usr directory is only writeable in the global zone which means within the host system. There is only read-only access available within the local zone (i. e. within the virtual environments). This may cause problems if you want to install a SAP system within a zone due to the fact SAPInst requires /usr as installation directory. A workaround is to create an alias in the global zone which links e.g. to /sap. This way you may create a directory named /sap within the local zone’s root directory and the installer is linked to this directory automatically. Local/ Global filesystem
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Mingzuo Shen
    During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.
  2. Wolfgang Pungartnik
    Hi Mark,

    interesting blog but unfortunately i need to add some more informations about the “read-only” file systems.

    It’s true that using so called “sparse root” zones there are some read-only file systems (/lib, /platform, /sbin, /usr) by default. If that causes any problems and you don’t want to use overlay file systems there’s always the possibility to create a “whole root” zone. Using “create -b” with zonecfg you may create a zone without any read-only file system. While sparse root zones share the same /usr file system each whole root zone has it’s own (read and write). As a drawback of this method you need more disk space for whole root zones but sometimes this may be better than other solutions.



Leave a Reply