DB2 10.5 for Linux, UNIX, and Windows

VM Mobility

Virtual machine (VM) mobility is a virtualization feature that enables you to move a VM from one physical host to another.

On supported Linux operating systems in a DB2® pureScale® instance, you can configure the guest VM to be a DB2 pureScalemember or a cluster caching facility (CF). If you move a VM to another physical host, you are moving the member or CF on that VM to another physical host. LIVE mobility enables you to move a VM from one physical host to another without stopping the VM. However, LIVE mobility of a guest VM containing a running member or CF is not supported.

VM mobility is supported for DB2 pureScale in both KVM and VMware environments. If you want to move a VM that contains a DB2 pureScale member or CF, you must meet the following requirements:
  • Use TCP/IP as the transport method.
  • Use virtual disks with SAN storage. You can use RDM disks with SAN storage in VMware environments.
  • Use virtual NICs.
  • Meet hypervisor-specific requirements for VM mobility support.

Before you move a VM containing a DB2 member or CF, you must first stop the member or CF by using the db2stop <member> with the QUIESCE option. Then remove the VM host from the DB2 cluster by putting the host into maintenance mode. After the VM is moved, you can add the host back to the DB2 pureScale cluster by removing the host from maintenance mode and restarting the member or the CF.

With workload balancing (WLB) and automatic client reroute (ACR) features in DB2 pureScale, transactions are automatically moved to other running members while you stop the member. After the move completes and the member is restarted, transactions are automatically moved back to that member.


You can monitor the VM resource consumption by DB2 processes, such as processor and memory usage, by using existing VM management tools.

You must ensure that you have sufficient processor resources to monitor the RSCT of cluster resources. If you do not have sufficient processor resources, you might have unexpected failures, such as killing the CF or member on that VM or the cluster might hang.