Skip to Content

Moving installed SAP systems in Sun Solaris 10 zones between hosts

This blog entry is about how to move installed SAP systems from one host to another one in about ten minutes. We will start with some few prerequisites and going on to the main subject of this blog: moving the SAP systems. We will guide you through the whole process by a step-by-step-guide. So let us start now.


If you want to move a SAP system in a zone, there are some prerequisites and considerations that need to be noted before starting to install SAP in zones and subsequently move them within the host system environment.

  • Move the zones only to a host on the same hardware platform, otherwise you can have potential source of quite intensive administrative tasks.
  • Install the central instance and database instance in two different zones on two different storage locations. These storage locations have to be movable, meaning that whenever you move the zones, you also have to move the storage location. This task can be achieved very easily by using Storage Area Network (SAN) or local storage, like SCSI/SAS drivers.
  • To make the operations much easier, we recommend to install the central instance and database instance using ZFS pools.
  • Store the zone configuration in a separate file within a separate directory of the ZFS pool.

Starting configuration

In our scenario we have two hosts, two zones and two ZFS pools. Have a look on the following picture for more information:

We intend to move the zones from hosts one and two to the new hosts three and four, because the later ones have more capable hardware, which is strongly needed.
Furthermore we do not intend to reinstall the central instance or the database instance. Of course, data loss can not be tolerated but we are willing to accept a short interruption of normal service that is ideally minimized. In the target configuration the two zones are running on host three and four and are still stored on the SAN. The old hosts are disconnected from the SAN. The next subsection shows the necessary steps to move from the initial to the target setting in a step-by-step fashion.

Moving a SAP system onto new host

This step-by-step guide is intended to show all necessary steps for moving an SAP system’s zones to the two new hosts. If you follow this instruction, the process should be straight forward and no difficulties are to be expected.

  1. h4. Shut down SAP system

    Connect to the zone G62AS1 and shut down the contained SAP system. An example thereof is given in the following command line statements.

  1. ssh G62AS1

Last login: Wed Jan 31 14:43:26 2007 from
Sun Microsystems Inc. SunOS 5.10   Generic Januar 2005
G62AS1# su – g62adm
g62adm> stopsap R3

The stopsap script stops the central instance and the central services. Then it is necessary to disconnect from zone G62AS1 and in turn establish a connection to zone G62DB1. Within this zone the stopdb script is used to stop the MaxDB instance.

G62AS1# exit
Connection to G62AS1 closed.

  1. ssh G62DB1

Last login: Wed Jan 31 14:45:26 2007 from
Sun Microsystems Inc. SunOS 5.10   Generic Januar 2005
G62DB1# su – g62adm
g62adm> stopdb

    1. h4. Shut down and detach zones

      For disconnecting both zones, we have to stop them first. After stopping each zone, we detach it.
      Shut down and detach the first zone:

  1. ssh host1

Last login: Wed Jan 31 14:48:26 2007 from
Sun Microsystems Inc. SunOS 5.10   Generic Januar 2005
host1# zoneadm –z G62AS1 halt
host1# zoneadm –z G62AS1 detach

Now, let’s shut down and detach the second zone:

  1. ssh host2

Last login: Wed Jan 31 14:49:26 2007 from
Sun Microsystems Inc. SunOS 5.10   Generic Januar 2005
host2# zoneadm –z G62DB1 halt
host2# zoneadm –z G62DB1 detach
h4. Attach the zones

Before attaching the zones to the new hosts, we will have to validate the zone configuration. It is therefore necessary to have a look into the zone configuration and, if necessary , update the interface name.
Right after this step, usually the installation of the zone would follow. However it was already installed on the old host, which is why zoneadm will respond with an error message, if you try to install the zone. Also if you try to boot the zone, zoneadm will give you an error too, complaining that the zone has to be installed firstly.

host3# zoneadm -z G62AS1 boot
zoneadm: zone 'G62AS1': must be installed before boot.
host3# zoneadm -z G62AS1 install
Cannot install detached zone.
Use attach or remove /zfsg62/G62 directory.
could not verify zonepath /zfsg62/G62 because of the above errors.
zoneadm: zone G62AS1 failed to verify

So instead of installing or booting the zone, the zoneadm attach command needs to be issued, which simply attachs the zone. After attaching, the zone can be booted.

host3# zoneadm -z G62AS1 attach
host3# zoneadm -z G62AS1 boot

Hint: Similarly we have to do the same procedure on host four, which contains the database instance zone. Having successfully performed all indicated steps, the zones are now up and running and the restart of the SAP system can begin.

    1. h4. Start database and central instance

      We connect to both zones and start the central instance and the database instance which will look similar to the following command line snippet.

  1. ssh g62db1

Last login: Wed Jan 31 15:56:26 2007 from
Sun Microsystems Inc. SunOS 5.10   Generic Januar 2005
G62db1# su – g62adm
g62adm> startdb

  1. ssh g62as1

Last login: Wed Jan 31 15:56:26 2007 from
Sun Microsystems Inc. SunOS 5.10   Generic Januar 2005
g62as1# su – g62adm
g62adm>startsap all
After restarting the SAP system, we ensure that it is operational by connecting to it via the SAPGui or via HTTP Web Browser.</li>

Quick Review

We showed how to move a SAP system from one host to another using Solaris’ virtualization concept – zones. As pointed out, only a small number of steps are necessary to achieve this goal. In hosting scenarios, where you have to deal with peak loads in a timely fashion, this is a great advantage. This is especially true, since Solaris’ concept offers potential for automating the steps necessary to move a zone. This could be exploited by creating a simple tool, which switches zones from one host to another.
As we stated, although it is possible to move and then boot a zone from e.g. a SPARC host to a x64 host, it is very difficult to develop a full adaptive environment based on zone. This difficulty arises from the fact that the SAP and MaxDB kernels are hardware-specific, implying that you can not use the MaxDB kernel for Solaris SPARC on a Solaris x64 platform and the other way around. The same is true for the SAP kernel.

h4.  Note:

This blog entry was made possible by the Sun Early Experience Lab at Technische Universitaet Muenchen ( and the SAP University Alliance Program (

Be the first to leave a comment
You must be Logged on to comment or reply to a post.