ESX Version 2

This section of the chapter excerpt will examine the features of VMware ESX Version 2 and how they can help with disaster recovery and backup.

By: Edward L. Haletky

Solution provider takeaway: This section of the chapter excerpt from the book VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers will focus on VMware ESX Server Version 2.

Download the .pdf of the chapter here.

The vmsnap_all and scripts provide a scripted mechanism to create a crash-consistent backup image that can be placed on any file system, because the process followed is to place the VM into REDO mode, export the VM, and commit the REDO. Because the VM was exported and not just copied, any file system will work. Many vendor tools make use of the functionality local to the ESX Server to make backups. However, vmsnap_all and will not work on nonrunning VMs, and those need to be exported and backed up using a traditional script.

The only change to the ESX v3 script presented above for earlier versions is to change the vcbMounter command to use with the appropriate arguments to send backups to local storage.

However, if the backup of a nonrunning VM is made to look the same as the ones produced by, the script can be used to restore them. The following script produces an ESX v2.5 backup of a nonrunning VM that will work with



if [ -f $VMX ]


vmd=`dirname $VMX`

vmp=`basename $vmd`

mkdir /vmimages/localbackup/$vmp

cp $VMX /vmimages/localbackup/$vmp

cp $vmd/nvram /vmimages/localbackup/$vmp/$vmp.nvram

cp $vmd/vmware.log.* /vmimages/localbackup/$vmp/

# Get list of SCSI devices

for x in `grep scsi $VMX|grep : |grep present| grep TRUE | awk

'{print $1}'`


y=`basename $x .present`

z=`grep $ $VMX | awk '{print $3}'`

vmkfstools --e $vmp.$vmp.vmdk $z



ESX Version Earlier Than 2.5.0

Before ESX version 2.5.0, users and vendors had to create their own scripts. These scripts would place a running VM in REDO mode and either copy the data to another VMFS or export to another file system. Often, these VMs were backed up to tape directly from the VMFS, which will produce a tape image that can only be restored to another VMFS, which limits its functionality.

Local Tape Devices

Other than these methods, ESX does not have the tools necessary to directly control tape libraries or tapes installed by default. Therefore, these are not recommended to be used. Local tape devices and libraries require two things: a specific Adaptec SCSI HBA and software to control the robot or tape. The software is extremely easy to find, but once installed is not really supported by VMware or other support organizations. Either way, when there is a problem with the local tape or tape library device, the ESX Server often has to be rebooted, and although it is possible to remove and reload the appropriate kernel module, some devices are not fully reconfigured unless they are seen at boot time. This is a failing in the COS version, the drivers used, and how the device or devices are allocated. On ESX version 3, all devices are assigned to the VMkernel, which implies a failure of the device for some reason could still require a reboot of the ESX Server. Using tape devices and libraries attached to remote archive servers is the recommended choice if possible.

In Chapter 4, it is suggested that you install mtx, which is a tool to manipulate tape libraries. MTX is vital to manipulate tape libraries from within ESX. But it often requires some form of scripting to use it properly. Specifically, there is a combination of tools necessary to properly manipulate tapes and the robotics of the libraries. The combination is MT and MTX. MT is found on the ESX media. Both of these tools use SCSI protocols to communicate with the tape and robot, respectively. Included is a simple script that can be used to manipulate a robot and tape device to flip tapes as necessary. If you must roll your own backup solution that uses a local tape device, this is invaluable and is often an inherent part of other solutions.

The following script takes two arguments, one to specify the tape device to use and the second is the tape volume to use. This is exactly the arguments the Linux dump command issues to a tape-changing script when dump is given the --F option. Before proceeding, it is best to become familiar with dump and other backup tools. There are several references available in the "References" element at the end of this book. In addition to taking arguments, the script uses three files to define its actions, all of which are located in /usr/local/etc.

The basic use of the following script is to rewind a given tape, eject it if necessary, and then use the robot to unload the current tape, store it in the proper slot, and reload the tape device with a new tape. When the new tape is loaded into the tape device, the script waits until it is available for write before returning to whatever program called it, which could be another script, a tool such as dump, or something else:

#!/bin/ksh --x

# Manipulate Tape Library and Tape device.

# Get args



echo "$dev $vol"

# read slot files




mslo=`/bin/cat $MAXS`

slot=`/bin/cat $SLOT`

# Find the device number

d=`echo $dev| /usr/bin/wc -c|/bin/sed 's/[t ]//g'`

let d=$d-1

dnum=`echo $dev | /usr/bin/cut -c $d`

# let dnum=$dnum-1

# force rewind device

# Rewind and unload tape:


while [ $skiptape -eq 1 ]


st=`echo $dev|/bin/sed 's/n//'`

/bin/mt -f $st rewind

# /bin/mt -f $st offline

/usr/local/sbin/mtx unload $slot $dnum

let slot=$slot+1

# wrap for now. Be sure we are on even borders however!

if [ $slot -gt $mslo ]


if [ $vol -eq 0 ]




# if in a volume 'abort'

echo 0 > $SLOT

exit 2



# keep track of where we are

echo $slot > $SLOT

if [ ! -z "$TAPELABEL" ]


echo "$slot $TAPELABEL $vol" >> $HIST


# load tape.

/usr/local/sbin/mtx load $slot $dnum

# only release when tape is available for write



while [ Z"$rc" != Z"true" ]


let i=$i+1

/bin/sleep 10

msg=`/bin/mt -f $st status | /usr/bin/tail -1`

rc=`echo $msg | /usr/bin/awk '/WR_PROT/ {print "skip"}'`

if [ Z"$rc" = Z"skip" ]


rc = "true";


rc=`echo $msg | /usr/bin/awk '/ONLINE/ {print "true"}'`


# reached timeout of 120 seconds

if [ $i -gt 24 ]


exit 2



rc=`echo $msg | /usr/bin/awk '/WR_PROT/ {print "skip"}'`

if [ Z"$rc" != Z"skip" ]





# this is goodness

sleep 20

exit 0

In addition to being able to roll your own via the service console, it is also possible to connect a VM to a local tape device. In this case, a VM is attached to a local tape device using the SCSI generic devices available when building a VM. The virtual SCSI device ID must match the physical SCSI device ID in these cases, and the device needs to be multitarget and not multi-LUN; in other words, multiple device IDs should be present and not multiple LUNs for the same device ID. The latter is not supported under any version of ESX. However, a VM attached to the local SCSI tape or tape library should have its SCSI HBA assigned to the VMs, as is the case with ESX version 3, so that there is no contention on the device.

VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers
  Disaster recovery and backup - introduction
 Business continuity
  ESX Version 2
 Vendor tools

About the book

VMware ESX Server in the Enterprise: Planning and Securing Virtualization Servers is the definitive, real-world guide to planning, deploying, and managing today's leading virtual infrastructure platform in mission-critical environments.. Purchase the book from Prentice Hall.

Reproduced from the book VMware ESX Server in the Enterprise. Copyright 2008, Prentice Hall. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other uses.

Dig Deeper on Storage Backup and Disaster Recovery Services