You are here: Full server to ESX appliance protection > Full server to ESX appliance requirements

Full server to ESX appliance requirements

Use these requirements for full server to ESX appliance protection.

Source server—The source server can be a physical or virtual server running any of the following Red Hat Enterprise Linux, Oracle Enterprise Linux, and CentOS operating systems.
- Operating system version—5.7 through 5.8
  - Kernel type for x86 (32-bit) architectures—Default, SMP, Xen, PAE
  - Kernel type for x86-64 (64-bit) architectures—Default, SMP, Xen
  - File system—Ext3, Ext4, XFS
- Operating system version—6.2 through 6.3
  - Kernel type for x86 (32-bit) architectures—Default
  - Kernel type for x86-64 (64-bit) architectures—Default
  - File system—Ext3, Ext4, XFS (64-bit only)
Oracle Enterprise Linux support is for the mainline kernel only, not the Unbreakable kernel.
Packages—Your Linux server must have the following packages installed before you can install and use Double-Take Availability. See your operating system documentation for details on these packages and utilities.
- lsb
- parted
- /usr/bin/which
- /usr/sbin/dmidecode
- /usr/bin/scp (only if you will be performing push installations from the Double-Take Console to your source servers)
Target host server—The target host server must be an ESX server. It can be any of the following ESX operating systems.
- ESX 4.1 Standard, Advanced, Enterprise, or Enterprise Plus
- ESXi 4.1 Standard, Advanced, Enterprise, or Enterprise Plus
- ESXi 5.0 Standard, Enterprise, or Enterprise Plus
- ESXi 5.1 Standard, 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.
Virtual recovery appliance—The target ESX host must have an existing virtual machine, known as a virtual recovery appliance. This will be an OVF (Open Virtualization Format) virtual machine included with Double-Take. You must install this virtual machine before you can establish protection. When you establish protection, the virtual recovery appliance will create a new virtual machine, mount disks, format disks, and so on. If failover occurs, the new virtual machine is detached from the virtual recovery appliance and powered on. Once the new virtual machine is online, it will have the identity, data, and system state of the source. Since the virtual recovery appliance maintains its own identity, it can be reused for additional failovers. Keep in mind the following caveats for the virtual recovery appliance.

The virtual recovery appliance must be a standalone virtual machine.
It should not reside in any multiple virtual machine vApp.
The appliance is pre-configured for optimal performance. You do not need to modify the memory, CPU, or other configurations.
You should not install or run anything else on this appliance.
The firewall is disabled and should remain disabled.
A single virtual recovery appliance can protect a maximum of 59 volume groups and raw block devices (combined) from any number of sources.

vCenter—Although vCenter is not required, if you are using it, then you must use version 4.1 or later.
vMotion—Host vMotion is only supported if you are using vCenter. Storage vMotion is not supported.
System memory—The minimum system memory on each server should be 1 GB. The recommended amount for each server is 2 GB.
Disk space for program files—This is the amount of disk space needed for the Double-Take program files. This is approximately 285 MB a Linux source server. The appliance is approximately 620 MB.

Approximately 45 MB will be on your /root partition, 40 MB on your /usr partition, and 200 MB in /opt.

Make sure you have additional disk space for Double-Take queuing, logging, and so on.
Server name—Double-Take includes Unicode file system support, but your server name must still be in ASCII format. If you have the need to use a server's fully-qualified domain name, your server cannot start with a numeric character because that will be interpreted as an IP address. Additionally, all Double-Take servers and appliances must have a unique server name.
Protocols and networking—Your servers must meet the following protocol and networking requirements.
- Your servers must have TCP/IP with static IP addressing.
- IPv4 is the only supported version.
Name resolution—Your servers must have name resolution or DNS. The Double-Take Console must be able to resolve the virtual recovery appliance, and the virtual recovery appliance must be able to resolve all source servers. For details on name resolution options, see your Linux documentation or online Linux resources.
Ports—Port 1501 is used for localhost communication. Ports 1500, 1505, 1506, 6325, and 6326 are used for component communication and must be opened on any firewall that might be in use.
Security—Double-Take security is granted through membership in user groups. The groups can be local or LDAP (Lightweight Directory Access Protocol). A user must provide a valid local account that is a member of the Double-Take security groups
SELinux policy—SELinux should be disabled on the source.
Snapshots—Double-Take snapshots are not supported with full server to ESX appliance jobs.

Supported configurations—The following table identifies the supported configurations for a full server to ESX appliance 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
Upgrade configuration²	Upgrade 4.7 Replication Console connection to 7.0 full server to ESX appliance job		X
Upgrade configuration²	Upgrade 6.0 full server to ESX appliance job to 7.0 full server to ESX appliance job		X
Version 7.0 console	Version 7.0 console can view or create job for 4.7 source and 4.7 target		X
	Version 7.0 console can create job for 6.0 source and 6.0 target		X
	Version 7.0 console can create job for 7.0 source and 7.0 target	X

See Supported configurations for details on each of the source to target configurations.
When upgrading from version 4.7, you will have to delete the existing connection before the upgrade and create a new job after the upgrade.When upgrading from version 6.0, delete the existing 6.0 job, upgrade your source, deploy a new appliance, and then create a new 7.0 job.