One of the powers of virtualization is the capability to quickly bring up a system in the case of a disaster. Examples may include a motherboard failure, a human error that has corrupted the existing virtual machine (VM), or a site disaster that requires multiple machines to be recovered.
The basic steps involved in using Xen for a disaster recovery scenario are:
- Ensure regular export images are created
- Place the exported image on the disaster recovery Xen hypervisor
- Bring the exported image up on the disaster recovery Xen hypervisor
Steps 1 -3 are covered below. In addition to steps 1-3, additional steps will be needed if the recovery is to include a structured data recovery. (A structured data recovery is typically a database restore, where archive logs have been written to a tape drive or another host. This would require additional steps to restore the point from the Xen export until the last transaction recorded in the archive log is played back.)
To create an image that can be brought up on another Xen hypervisor (hardware based server running the Xen hypervisor), the virtual machine must be shut down and exported. Prior to exporting a virtual machine, the particular virtual machine must be shut down. To do this manually, execute:
[root@xen2 ~]# xe vm-shutdown vm-name="vmdeb1"
Since the VM must be shut down, the system down time must be weighed against how close the recovery system must be to the production
Requires Free Membership to View
When you register, my team of editors will also send you the latest expert resources covering all areas of server virtualization, such as platforms, architectures and strategies, server hardware, managing virtual environments, application issues and more.
Cathleen A. Gagne, Senior Editorial Director
system. On web and application servers, many environments can operate with an export once per week or once per month since the servers do not contain data.
To export the machine, we use the xe command and tell the xe command where to put the necessary files using the vm-export parameter.
[root@xen2 ~]# xe vm-export vm-name="vmdeb1" dir-name="/tmp/vmdeb1"
The xe command will then go through the steps necessary to create a virtual machine image that can be imported to another xen hypervisor. Upon completion of the export command the results will be at least one file and two directories: the configuration file (ova.xml), and a directory for each file system the system had, as seen by the ls command of the export just created:
[root@xen2 ~]# ls -l /tmp/vmdeb1/ total 12 -rw-r--r-- 1 root root 977 Feb 26 15:24 ova.xml drwxr-xr-x 2 root root 4096 Feb 26 15:28 sda drwxr-xr-x 2 root root 4096 Feb 26 15:28 sdb
Each of the directories will have multiple files that contain pieces of the file in the bzip2 format.
To make all the files more manageable to move to another system, an archive / tarball can be created, so that a single file can be moved around:
[root@xen2 ~]# cd /tmp [root@xen2 ~]# tar cvf vmdeb1.tar vmdeb1/
The tarball can be compressed; however, there is very little to gain since the file systems were compressed with the bzip2 algorithm during the export. To bring the virtual machine up on the DR machine, it needs to be copied to the DR system (named xen-dr here). After copying it to the DR system, the archive can be expanded:
[root@xen-dr disaster-recovery]# cd /disaster-recovery
[root@xen-dr disaster-recovery]# tar xvf vmdeb1.tar
[root@xen-dr disaster-recovery]# xe vm-import
-u root -pw ****** -h localhost dir-name=/disaster-recovery/vmdeb1/
While the import is running another terminal can be used to check the status of the vm-import:
[root@xen-dr /]# xe host-vm-list
NAME: vmdeb1
uuid: 5fff7acb-e793-4563-93b2-5f9a29cb753c
state: INSTALLING
Once the import is complete , the VM will show up as DOWN with the xe host-vm-list:
[root@xen-dr disaster-recovery]# xe host-vm-list
NAME: vmdeb1
uuid: 5fff7acb-e793-4563-93b2-5f9a29cb753c
state: DOWN
The VM vmdeb1 can now be brought up on the disaster recovery server:
[root@xen-dr disaster-recovery]# xe vm-start vm-name=vmdeb1
Some issues to watch
While in a disaster recovery, do not forget the status of the original machine and disaster machine. Inadvertently bringing up both systems will cause issues. In this same vain, remember that the exported VM will have the same IP address as the original, therefore, the receiving Xen hypervisor should be on a network that supports the IP addresses or the appropriate changes be made (IP, gateway, client, and DNS changes).
The images created with the xe vm-export should be guarded since the data can easily be restored to any system and the data compromised. Methods of protecting the data should follow general data center practices afforded systems and media. Due to the ease of exploiting the images, encryption of the tarball containing the images should also be considered.
About the author: Ronald McCarty is a freelance writer and consultant specializing in systems, network, and information security. He received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany and his master's degree in Management with a specialization in information technology at Capella University. Ron's company, Your Net Guard offers IT consulting and integration services in the Dallas/Forth Worth area. He can be reached at mccarty@mcwrite.net.
This was first published in March 2007