You are here: V to ESX protection > V to ESX requirements

V to ESX requirements

In addition to the Core Double-Take requirements, use these requirements for V to ESX protection.

Source virtual server—The source virtual server can be any of the operating systems listed in the Core Double-Take requirements. The source server does not need Double-Take 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 as described in the Core Double-Take requirements.

In order for the installation to be completed during the protection process, the Double-Take Console should have enough valid licenses in the license inventory for each of the virtual machines you are protecting. If you do not have enough valid licenses available, you will have to install Double-Take on each virtual machine individually and then restart each protection job. See Managing the Double-Take license inventory.
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 ESX can 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 4.0.x or 4.1 Standard, Advanced, Enterprise, or Enterprise Plus
ESXi 4.0.x or 4.1 Standard, Advanced, Enterprise, or Enterprise Plus
ESXi 5.0 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 ESX server must have ESX 4.0 update 1 or later.

vCenter—Although vCenter is not required, if you are using it, then you must use version 4.1 or later.

VMotion is only supported if you are using vCenter.
Virtual recovery appliance—The target ESX server 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.) You can optionally have an existing virtual recovery appliance on the source ESX server to reverse your protection if desired.

Operating system—The virtual recovery appliance can be any of the operating systems listed in the Core Double-Take 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—The virtual recovery appliance must have Double-Take installed and licensed on it.
Microsoft .NET Framework—Microsoft .NET Framework version 3.5 Service Pack 1 is required on the virtual recovery appliance. 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 CD, via a web connection during the Double-Take installation, or from a copy you have obtained manually from the Microsoft web site.
Snapshots—Do not take snapshots of the virtual recovery appliance, because they will interfere with proper failover.

Disk controller—VMware Paravirtual SCSI Controllers are not supported.
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.

Supported configurations—The following table identifies the supported configurations for a V to ESX job.

Configuration		Supported	Not Supported
Source to target configuration¹	One to one, active/standby	X
	One to one, active/active		X
	Many to one	X
	One to many	X
	Chained		X
	Single server	X
Server configuration²	Standalone to standalone	X
	Standalone to cluster	X
	Cluster to standalone	X
	Cluster to cluster		X
	Cluster Shared Volumes (CSV) guest level	X
	Cluster Shared Volumes (CSV) host level		X
Upgrade configuration³	Upgrade 5.3 Windows ESX to ESX job to 6.0 V to ESX job	X

See Supported configurations for details on each of the source to target configurations.
Supported cluster configurations can be used to protect a node, shared storage, or a virtual machine, however, there is no cluster resource or cluster-awareness with this configuration.
When upgrading, you can perform a rolling upgrade where you update the target server first. After the upgrade is complete, the source will automatically reconnect to the target. At this point, the job will be an unmanaged job that you can delete or failover. No other job controls will be available. Once you upgrade you source, the job will be fully controllable.