Use these instructions to protect a physical or virtual server, where you want to protect the volumes from the physical server or the volumes from within the virtual guest operating system, to a virtual server on a Hyper-V or ESX server.
Specify the source server that you want to protect. This is the physical or virtual server that you want to protect.
Note: |
If you enter the source server's fully-qualified domain name, the Double-Take Console will resolve the entry to the server short name. If that short name resides in two different domains, this could result in name resolution issues. In this case, enter the IP address of the server. Your source can have no more than four NICs enabled, except if your source is ESX version 4.x. In that case, you can have up to ten NICs. |
Choose the volumes on the source server that you want to protect.
Note: | If the size of the replica virtual machine is identical to the size of the source volume and the source has less than 20 MB of free disk space remaining, you may run out of disk space on the replica due to differences in how the virtual disk's block size is formatted. To avoid this issue, specify the size of your replica virtual machine to be at least 20 MB larger. |
Specify the target server. If you are protecting to a Hyper-V server, this is the name of the Hyper-V server. If you are protecting to a ESX server, this is the host name of your virtual recovery appliance.
Note: |
If you enter the target server's fully-qualified domain name, the Double-Take Console will resolve the entry to the server short name. If that short name resides in two different domains, this could result in name resolution issues. In this case, enter the IP address of the server. |
If you are protecting to an ESX server, specify the ESX server information for your target virtual recovery appliance.
If you are using a Hyper-V target, select a location on the target for the replica virtual machine.
If you are using an ESX target, select a location on the target for the replica virtual machine.
Use pre-existing virtual disks—You can reuse an existing virtual disk on your ESX target, rather than having Double-Take Availabilitycreate a virtual disk for you. This saves time by skipping the virtual disk creation steps and performing a difference mirror instead of a full mirror. In order to use a pre-existing virtual disk, it must be a valid VMware virtual disk. It cannot be attached to any other virtual machine, and the virtual disk size cannot be changed.
Because Double-Take Availability will skip the virtual disk creation steps when using a pre-existing disk, Double-Take Availability will instead copy your existing virtual disk to the default VMware new virtual machine location. Therefore, it is important that you do not place your existing virtual disk in the new folder location that VMware will create. Put the pre-existing virtual disk in a temporary location on the target. Specify this temporary location for Enter the folder name on the selected datastore which has pre-existing virtual disks.
In order for Double-Take Availability to find the pre-existing disk, the virtual disk file names must be formatted using the convention SourceServer_DriveLetter. For example, if your source server is Alpha and you are protecting drives C and D, Double-Take Availability will look for the file names Alpha_C.vmdk and Alpha_D.vmdk. If you are using IP addresses, substitute the IP address for the server name. For example, if the IP address for server Alpha is 172.31.10.25 then Double-Take Availability will look for the file names 172.31.10.25_C.vmdk and 172.31.10.25_D.vmdk.
If you originally created a virtual disk and specified the source server by its IP address, the pre-existing virtual disk file name cannot use the server name. However, you can rename that file and its associated -flat.vmdk file to use the IP address. The reverse is also true. If you originally specified the source server by its name, the pre-existing virtual disk file name cannot use the server’s IP address. However, you can rename the file and its associated -flat.vmdk to use the source name. For example, if you originally created a virtual disk and specified the source by its IP address, you need to rename the file source_name_drive.vmdk to source_IPaddress_drive.vmdk. You also need to rename the file source_name_drive-flat.vmdk to source_IPaddress_drive-flat.vmdk. The reverse (change source_IPaddress to source_name for both files) is also true. Additionally, you will need to edit the .vmdk file manually because it contains the name of the -flat.vmdk file. Modify the reference to the -flat.vmdk file to the new name you have specified using any standard text editor.
In a WAN environment, you may want to take advantage of the Use pre-existing virtual disks feature by using a process similar to the following.
Configure the replica virtual machine.
Specify your protection settings.
The fields on this screen will vary depending on if you are using an ESX target or a Hyper-V target.
Note: | To achieve shorter delays before failover, use lower interval and missed interval values. This may be necessary for servers, such as a web server or order processing database, which must remain available and responsive at all times. Lower values should be used where redundant interfaces and high-speed, reliable network links are available to prevent the false detection of failure. If the hardware does not support reliable communications, lower values can lead to premature failover. To achieve longer delays before failover, choose higher values. This may be necessary for servers on slower networks or on a server that is not transaction critical. For example, failover would not be necessary in the case of a server restart. |
Note: |
A maximum of three volumes can be attached to an IDE controller. If you are protecting more than three volumes on the source, you will need to install the Hyper-V Integration Components to acquire a SCSI device. See your Hyper-V documentation for more information. If your source is Windows 2003 or Windows 2008 with no service packs and you have selected a SCSI controller, you will need to manually install the Hyper-V Integration Components after failover to attach these volumes to the replica virtual machine. |