written by: Murray White - Solution Architect with Vision Solutions


The following video demonstrates how to protect Windows Virtual Guest machines running on a VMware ESX host, to another VMware ESX host.
Replication is performed real-time, asynchronously and at byte-level.

Features:

* Manage the entire protection workflow (installation, configuration, monitoring, failover, reverse protection) all from one console.

* Manage protection of individual or groups of virtual guest machines.

* Configuration performed from the ESX host level, but the protection of the virtual guests is from the virtual guest machine level.


Benefits:

* Individual VM failure or entire ESX host/site failure: Double-Take Console allows you to failover individual guest machines, or groups of guest machines with just a couple of clicks, from one ESX host to another ESX host, and vice-versa.

* Ease of Administration: All aspects of protection (install, config, monitor, failover, reverse protect) handled from within a single Double-Take Console.
The benefit of managing your protection jobs from the virtual host level, with the granularity of protection occurring at the virtual guest machine level.

* Server/Storage Agnostic: Underlying storage and/or ESX host server models do not have to match between ESX hosts.
Example: Production ESX host could have SAN-attached storage serving it's Datastores, and the Target/DR ESX host could have a different SAN-attached storage model or direct-attached storage for it's Datastores or vice-versa. ESX physical host server models do not have to match either. ie: Production ESX host server could be a 2U rack server and Target/DR ESX host server could be a Blade server.







V2V ESX-to-ESX Guest Machine Protection Requirements:

In addition to the core Double-Take Availability requirements, use these requirements for Windows ESX to ESX protection.

  • Source virtual server—The source virtual server can be any of the operating systems listed in the core Double-Take Availability requirements. The source server does not need Double-Take Availability installed on it. If it is not, the installation will be completed during the protection process, however the virtual must meet the Windows firewall requirements. In order for the installation to be completed during the protection process, the Double-Take Console should have enough licenses in the license inventory for each of the virtual machines you are protecting. If you do not have enough licenses available, you will have to install Double-Take Availability on each virtual machine individually and then restart each protection job.
  • Source and target ESX server—The ESX server that will host your source and target must be the same version of ESX. The version of ESXcan be any of the following. Note that ESX is commonly referred to as the Classic edition and ESXi as the Embedded and Installable edition.
  • ESX 3.5.x or ESXi 3.5.x Standard, Advanced, Enterprise, or Enterprise Plus
  • ESX 4.0.x or 4.1 or ESXi 4.0.x or 4.1 Standard, Advanced, Enterprise, or Enterprise Plus If you are using the Standard edition of ESX 4.0 or ESXi 4.0, you must have update 1 or later. If your source is a Windows 2008 R2 server, your ESXserver must have version 3.5 update 5 or later or ESX 4.0 update 1 or later.
  • VirtualCenter—Although VirtualCenter is not required, if you are using it, then you must use version 2.5 or later. VMotion is only supported if you are using vCenter.
  • Virtual recovery appliance—The ESXserver must have an existing virtual machine, known as a virtual recovery appliance, that meets the following requirements. (When you establish protection, the virtual recovery appliance will create new virtual servers, mount disks, format disks, and so on. If failover occurs, the new virtual machines are detached from the virtual recovery appliance and powered on. Once the new virtual machines are online, they will have the identity, data, and system state of their source. Since the virtual recovery appliance maintains its own identity, it can be reused for additional failovers.)
  • Operating system—The virtual recovery appliance can be any of the operating systems listed in the core Double-Take Availability requirements.
  • Operating system version—The virtual recovery appliance must have the same or newer operating system than the source (not including service pack level).
  • Operating system installation location—Because VMware boots from the first bootable volume that is discovered, the operating system must be installed to SCSI device 0, Slot 0 on the virtual recovery appliance.
  • Double-Take Availability—The virtual recovery appliance must have Double-Take Availability installed and licensed on it.
  • Microsoft .NETFramework—The virtual recovery appliance requires the Microsoft .NET Framework version 3.5 Service Pack 1. This version is not included in the .NET version 4.0 release. Therefore, even if you have .NET version 4.0 installed, you will also need version 3.5.1. You can install this version from the Double-Take Availability CD, via a web connection during the Double-Take Availability installation, or from a copy you have obtained manually from the Microsoft web site.
  • Domain controllers—If you are protecting a domain controller, it will start in a non-authoritative restore mode after failover. This means that if it was communicating with other domain controllers before failover, it will require one of those domain controllers to be reachable after failover so it can request updates. If this communication is not available, the domain controller will not function after failover. If this is the only domain controller, this is not an issue.