Problem solve Get help with specific problems with your technologies, process and projects.

Moving installed SAP systems in zones between hosts in ten minutes

How to move installed SAP systems from one host to another one in about ten minutes.

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.


  1. Move the zones only to a host on the same hardware platform, otherwise you can have potential source of quite intensive administrative tasks.

  2. 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.

  3. To make the operations much easier, we recommend to install the central instance and database instance using ZFS pools.

  4. Store the zone configuration in a separate file within a separate directory of the ZFS pool.

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.

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

  1. 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.

    # 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.

    g62adm> exit
    G62AS1# exit
    Connection to G62AS1 closed.
    # 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

  2. 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:

    # 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:

    # 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

  3. Now that the zones are offline and detached, we can export the underlying ZFS pools and ‘move’ them to the new host systems.

  4. Export ZFS pools

    In order to export the ZFS pools, we connect to the host one again and export the ZFS pool, which is named ‘zfs<sid>’.

    host1# zpool export zfsg62as1

    Exporting a ZFS pool means: stop all I/O, unmount the devices and export them. The same operation has to be done on the second host:

    host2# zpool export zfsg62db1

    After completing these steps, all the ZFS pools are logically disconnected from the host systems. In order to move the zones to the new hosts, we have to reconfigure the SAN and thus make the storage available for the two new hosts three and four.

  5. Disconnecting and connecting storage

    This chapter depends on what type of storage you use for your server. However, you will have to disconnect and connect the storage from the old hosts to the new ones. We will not show how to do this here.

  6. Import ZFS pools

    After the storages are connected, try to discover the exported ZFS pool:

    host3# zpool import
    no pools available to import

    Solaris’ information that no pools are available is no reason to worry. As we know the name of the pools we can force Solaris to import the pools by explicitly providing the pool’s name:

    host3# zpool import zfsg62as1

    The command will import the new ZFS pool and mount it to the initial directory. Having performed this step, the underlying storage is ready and the zones can now be attached.

  7. 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.

  8. 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.

    # 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

    # 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.

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.

Quick Review

Andre Boegelsack works as SAP and Solaris adminstrator at the SAP University Competence Center in Munich/Germany.

This content is reposted from the SAP Developer Network.
Copyright 2007, SAP Developer Network

SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.

Want to read more from this author? Click here to read Andre Boegelsack's Weblog. Click here to read more about Application Servers on SDN.

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.

Dig Deeper on SAP implementation

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.