Open topic with navigation

Windows ESX to ESX 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 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 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 ESX server 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 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.)
• 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 .NET Framework—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.