Open topic with navigation

Creating an agentless Hyper-V job

Use these instructions to create an agentless Hyper-V job.

1. Click Get Started from the toolbar.

2. Select Double-Take Availability and click Next.

3. Select Protect files and folders, an application, or an entire Windows server and click Next.

4. Choose your source server. This is the Hyper-V server or cluster that is hosting the virtual machines that you want to protect.If your virtual machines are on a cluster, select the cluster name, not the node name.

   

   • Current Servers—This list contains the servers currently available in your console session. Servers that are not licensed for the workflow you have selected will be filtered out of the list. Select your source server from the list.
   • Find a New Server—If the server you need is not in the Current Servers list, click the Find a New Server heading. From here, you can specify a server along with credentials for logging in to the server. If necessary, you can click Browse to select a server from a network drill-down list.

   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.

   When specifying credentials for a new server, specify a user that is a member of the local Double-Take Admin and local administrator security groups. The user must also have administrative rights for Microsoft Hyper-V.

    

5. Click Next to continue.

6. Choose the type of workload that you want to protect. Under Server Workloads, in the Workload types pane, select Agentless Hyper-V. In the Workload items pane, select the virtual machines on the Hyper-V source that you want to protect. The list of virtual machines will vary depending on whether your source is a Hyper-V server, cluster, or node.

   If the workload you are looking for is not displayed, enable Show all workload types. The workload types in gray text are not available for the source server you have selected. Hover your mouse over an unavailable workload type to see a reason why this workload type is unavailable for the selected source.

   

7. Click Next to continue.

8. Choose your target server. This is the Hyper-V server or cluster that will store the replicas of the virtual machines from the source.

   

   • Current Servers—This list contains the servers currently available in your console session. Servers that are not licensed for the workflow you have selected and those not applicable to the workload type you have selected will be filtered out of the list. Select your target server from the list.
   • Find a New Server—If the server you need is not in the Current Servers list, click the Find a New Server heading. From here, you can specify a server along with credentials for logging in to the server. If necessary, you can click Browse to select a server from a network drill-down list.

   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.

   When specifying credentials for a new server, specify a user that is a member of the local Double-Take Admin and local administrator security groups. The user must also have administrative rights for Microsoft Hyper-V.

    

9. Click Next to continue.

10. You have many options available for your agentless Hyper-V job. Configure those options that are applicable to your environment.

    All agentless Hyper-V jobs will have the following sections available on the Set Options page.

    • Replica Virtual Machine Configuration
    • Mirror, Verify & Orphaned Files
    • Network Route
    • Snapshots
    • Compression
    • Bandwidth

    If you are protecting just one virtual machine, you will also have the following sections.

    • General
    • Replica Virtual Machine Location
    • Replica Virtual Machine Network Settings
    • Failover Monitor
    • Failover Identity

    If you are protecting more than one virtual machine, you will have the Replica Virtual Machines section instead, which is similar to the location section.

    As you can see, if you are protecting more than one virtual machine, there are a few settings that you will not have access to during job creation. In this case, default values will be used. You can modify the default values after the jobs have been created.

     

    Click a link below to see the options available for that section of the Set Options page.

    General

    

    For the Job name, specify a unique name for your job.

    Replica Virtual Machines

    

    • Target Volume—For each virtual machine you are protecting, specify the volume where you want to store the replica virtual machine on the target.
    • Target Path—For each virtual machine you are protecting, specify a path on the selected Target Volume where you want to store the replica virtual machine on the target.
    • Show additional target volumes information—Click this link to see storage information for the volumes on your target. This will help you select the appropriate volumes for your replica virtual machines.

    If your target is a cluster, you will only see the clustered volumes that have been added to the cluster prior to creating the job. If the target is a cluster node, you will only see non-clustered volumes.

     

    Replica Virtual Machine Location

    

    • Select the volume and folder on the target server that will hold the replica virtual machine—Select one of the volumes from the list to indicate the volume on the target where you want to store the new virtual server when it is created. The target volume must have enough Free Space to store the source data. If your target is a cluster, you will only see the cluster aware volumes that have been added to the cluster prior to creating the job.
    • Full path where the replica virtual machine will be stored—Specify a location on the selected Volume to store the replica of the source. By specifying an existing folder, you can reuse an existing virtual machine on your Hyper-V target created by a previous protection job. This can be useful for pre-staging data on a virtual machine over a LAN connection and then relocating it to a remote site after the initial mirror is complete. You save time by performing a difference mirror instead of a full mirror. In order to use a pre-existing virtual disk, it must be a valid virtual disk and it cannot be attached to any registered virtual machine. In a WAN environment, you may want to take advantage of re-using an existing virtual disk by using a process similar to the following.
    1. Create a protection job in a LAN environment, letting Double-Take create the virtual disk for you.
    2. Complete the mirror process locally.

    3. Delete the protection job and when prompted, select to keep the replica.

       Even though you are keeping the replica virtual machine, it is not registered with the Hyper-V Manager. If you want to use the replica machine, you will have to register it. However, you do not need to register it to reuse the disks in Double-Take. Double-Take will automatically register the virtual machine at failover time.

        

    4. Shut down and move the Hyper-V target server to your remote site.

    5. After the Hyper-V target server is back online at the remote site, create a new protection job for the same source server. Double-Take will reuse the existing hard disk files and perform a difference mirror over the WAN to bring the virtual machine up-to-date.

    Replica Virtual Machine Configuration

    

    • Replica virtual machine display name—Specify the name of the replica virtual machine. This will be the display name of the virtual machine on the host system. 
    • Map source virtual switches to target virtual switches—Identify how you want to handle the network mapping after failover. The Source Network Adapter column lists the NICs from the source. Map each one to a Target Network Adapter, which is a virtual network on the target. You can also choose to failover the NIC and IP addresses but leave them in a not connected state.
    • Map source VLAN ID to target VLAN ID—If your environment is a virtual local area network, identify how you want to handle the VLAN IDs after failover. Map each Source VLAN ID to a Target VLAN ID. If you reconfigure your VLAN IDs after you have created your job, you will need to edit the job to update your VLAN mappings, if you want to use the new configuration.
    Replica Virtual Machine Network Settings

    

    If your virtual machine is powered on and has Integration Services available, this option will allow you to configure advanced settings, which are used primarily for WAN support. Before you can set these options, you must provide credentials for the virtual machine you are protecting. Click the link Provide source virtual machine credentials to use advanced network configuration and specify the Guest Host name, User name, Password, Domain, and click OK

    • Use advanced settings for replica virtual machine network configuration—This option allows you to configure advanced network settings, which are primarily for WAN support.

    • Source network adapter—Select a network adapter on the source and specify the Target IP addresses, Default Gateways, and DNS Server addresses to be used after failover. If you add multiple gateways or DNS servers, you can sort them by using the Move Up and Move Down buttons. Repeat this step for each network adapter on the source.

      Updates made during failover will be based on the network adapter name when protection is established. If you change that name, you will need to delete the job and re-create it so the new name will be used during failover.

      If you update one of the advanced settings (IP address, gateway, or DNS server), then you must update all of them. Otherwise, the remaining items will be left blank. If you do not specify any of the advanced settings, the replica virtual machine will be assigned the same network configuration as the source.

      By default, the source IP address will be included in the target IP address list as the default address. If you do not want the source IP address to be the default address on the target after failover, remove that address from the Target IP address list.

       

    Failover Monitor

    

    • Monitor for failover—Select this option if you want the target to actively monitor the source for a failure. If you disable this option and do not monitor for failover, the target will not actively monitor the source for a failure. In this case, you will have to monitor the source manually on your own and initiate failover manually if there is a source failure.

    • Total time to failure—Specify, in hours:minutes:seconds, how long the target will keep trying to contact the source before the source is considered failed. This time is precise. If the total time has expired without a successful response from the source, this will be considered a failure.

      Consider a shorter amount of time for servers, such as a web server or order processing database, which must remain available and responsive at all times. Shorter times 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, shorter times can lead to premature failover. Consider a longer amount of time for machines 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.

    • Consecutive failures—Specify how many attempts the target will make to contact the source before the source is considered failed. For example, if you have this option set to 20, and your source fails to respond to the target 20 times in a row , this will be considered a failure.

    • Monitor on this interval—Specify, in hours:minutes:seconds, how long to wait between attempts to contact the source to confirm it is online. This means that after a response (success or failure) is received from the source, Double-Take will wait the specified interval time before contacting the source again. If you set the interval to 00:00:00, then a new check will be initiated immediately after the response is received.

      If you choose Total time to failure, do not specify a longer interval than failure time or your server will be considered failed during the interval period.

      If you choose Consecutive failures, your failure time is calculated in one of two ways.

      • ICMP enabled—If ICMP is enabled on your host when the job is created, your failure time is calculated by the length of time it takes your host to respond to an ICMP host ping plus the length of time it takes your virtual machine to respond plus the interval time between these two checks, times the number of consecutive failures that can be allowed. That would be (ICMP host response time + virtual machine response time + interval) * failure number. If the ICMP check fails, the virtual machine check is skipped and the ICMP check will reoccur after the interval time.
      • ICMP disabled—If ICMP is disabled on your host when the job is created, your failure time is calculated by the length of time it takes your virtual machine to respond plus the interval time between each response, times the number of consecutive failures that can be allowed. That would be (virtual machine response time + interval) * failure number.

      Keep in mind that timeouts from a failed check are included in the response times, so your failure time will not be precise.

    • Wait for user to initiate failover—If you are monitoring for failover, when a failure occurs you can have Double-Take automatically initiate the failover process or wait for you to initiate it. When this option is enabled and a failure occurs, the job will wait in Failover Condition Met for you to manually initiate the failover process. When this option is disabled, failover will occur immediately when a failure occurs.
    Failover Identity

    

    • Retain target network configuration—The target will retain all of its original IP addresses.

      • Update DNS server—Specify if you want Double-Take to update your DNS server on failover. If DNS updates are made, the DNS records will be locked during failover. Be sure and review the Core Double-Take requirements for the requirements for updating DNS.

        DNS updates are not available for Server Core servers or source servers that are in a workgroup.

         

        Expand the DNS Options section to configure how the updates will be made. The DNS information will be discovered and displayed. If your servers are in a workgroup, you must provide the DNS credentials before the DNS information can be discovered and displayed.

        • Change—If necessary, click this button and specify a user that has privileges to access and modify DNS records. The account must be a member of the DnsAdmins group for the domain, and must have full control permissions on the source's A (host) and PTR (reverse lookup) records. These permissions are not included by default in the DnsAdmins group.
        • Remove—If there are any DNS servers in the list that you do not want to update, highlight them and click Remove.
        • Update these source DNS entries with the corresponding target IP address—For each IP address on the source, specify what address you want DNS to use after failover. For clusters, be sure and select the clustered IP address.
        • Update TTL—Specify the length of time, in seconds, for the time to live value for all modified DNS A records. Ideally, you should specify 300 seconds (5 minutes) or less.

      If you select Retain your target network configuration but do not enable Update DNS server, you will need to specify failover scripts that update your DNS server during failover, or you can update the DNS server manually after failover. This would also apply to non--Microsoft Active Directory Integrated DNS servers. You will want to keep your target network configuration but do not update DNS. In this case, you will need to specify failover scripts that update your DNS server during failover, or you can update the DNS server manually after failover.

      DNS updates will be disabled if the target server cannot communicate with both the source and target DNS servers

       

    Mirror, Verify & Orphaned Files

    

    • Mirror all files—All protected files will be mirrored from the source to the target.
    • Mirror different files—Only those protected files that are different based on date and time, size, or attributes will be mirrored from the source to the target.
      • Mirror only if the file on the source is newer than the copy on the target—This option is not available for agentless Hyper-V jobs.
      • Use block checksum for comparisons—For those files flagged as different, the mirroring process can perform a block checksum comparison and send only those blocks that are different.
      File Differences Mirror Options Compared

      The following table will help you understand how the various difference mirror options work together, including when you are using the block checksum option configured through the Source server properties.

      An X in the table indicates that option is enabled. An X enclosed in parentheses (X) indicates that the option can be on or off without impacting the action performed during the mirror.

      Not all job types have the source newer option available.

      Source Server Properties	Job Properties			Action Performed
      Block Checksum Option	File Differences Option	Source Newer  Option	Block Checksum Option
      (X)	X			Any file that is different on the source and target based on the date, time, size, and/or attribute is transmitted to the target. The mirror sends the entire file.
      (X)	X	X		Any file that is newer on the source than on the target based on date and/or time is transmitted to the target. The mirror sends the entire file.
      	X		X	Any file that is different on the source and target based on date, time, size, and/or attributed is flagged as different. The mirror then performs a checksum comparison on the flagged files and only sends those blocks that are different.
      X	X		X	The mirror performs a checksum comparison on all files and only sends those blocks that are different.
      (X)	X	X	X	Any file that is newer on the source than on the target based on date and/or time is flagged as different. The mirror then performs a checksum comparison on the flagged files and only sends those blocks that are different.

    • Enable scheduled verification—Verification is the process of confirming that the source replica data on the target is identical to the original data on the source. Verification creates a log file detailing what was verified as well as which files are not synchronized. If the data is not the same, can automatically initiate a remirror, if configured. The remirror ensures data integrity between the source and target. When this option is enabled, Double-Take will verify the source replica data on the target and generate a verification log.

      Because of the way the Windows Cache Manager handles memory, machines that are doing minimal or light processing may have file operations that remain in the cache until additional operations flush them out. This may make Double-Take files on the target appear as if they are not synchronized. When the Windows Cache Manager releases the operations in the cache on the source and target, the files will be updated on the target.

       

    • Verify on this interval—Specify the interval between verification processes.
    • Begin immediately—Select this option if you want to start the verification schedule immediately after the job is established.
    • Begin at this time—Select this option if you want to start the verification at the specified date and time.
    • Mirror files to the target server when verifying—When this option is enabled, in addition to verifying the data and generating a log, Double-Take will also mirror to the target any protected files that are different on the source.
    • Mirror only if the file on the source is newer than the copy on the target—This option is not available for agentless Hyper-V jobs.
    • Use block checksum for comparisons—For those files flagged as different, the mirroring process can perform a block checksum comparison and send only those blocks that are different.

    • Calculate size of protected data before mirroring—Specify if you want Double-Take to determine the mirroring percentage calculation based on the amount of data being protected. If the calculation is enabled, it is completed before the job starts mirroring, which can take a significant amount of time depending on the number of files and system performance. If your job contains a large number of files, for example, 250,000 or more, you may want to disable the calculation so that data will start being mirrored sooner. Disabling calculation will result in the mirror status not showing the percentage complete or the number of bytes remaining to be mirrored.

      The calculated amount of protected data may be slightly off if your data set contains compressed or sparse files.

       

    • Delete orphaned files—An orphaned file is a file that exists in the replica data on the target, but does not exist in the protected data on the source. This option specifies if orphaned files should be deleted on the target during a mirror, verification, or restoration.

      Orphaned file configuration is a per target configuration. All jobs to the same target will have the same orphaned file configuration.

      The orphaned file feature does not delete alternate data streams. To do this, use a full mirror, which will delete the additional streams when the file is re-created.

      If delete orphaned files is enabled, carefully review any replication rules that use wildcard definitions. If you have specified wildcards to be excluded from protection, files matching those wildcards will also be excluded from orphaned file processing and will not be deleted from the target. However, if you have specified wildcards to be included in your protection, those files that fall outside the wildcard inclusion rule will be considered orphaned files and will be deleted from the target.

      If you want to move orphaned files rather than delete them, you can configure this option along with the move deleted files feature to move your orphaned files to the specified deleted files directory. See Target server properties for more information.

      During a mirror, orphaned file processing success messages will be logged to a separate orphaned file log. This keeps the Double-Take log from being overrun with orphaned file success processing messages. Orphaned files processing statistics and any errors in orphaned file processing will still be logged to the Double-Take log, and during difference mirrors, verifications, and restorations, all orphaned file processing messages are logged to the Double-Take log. The orphaned file log is located in the Logging folder specified for the source. See Log file properties for details on the location of that folder. The orphaned log file is overwritten during each orphaned file processing during a mirror, and the log file will be a maximum of 50 MB.

       

    Network Route

    

    This section is not applicable if your target is a cluster.

     

    For Send data to the target server using this route, Double-Take will select, by default, a target route for transmissions. If desired, specify an alternate route on the target that the data will be transmitted through. This allows you to select a different route for Double-Take traffic. For example, you can separate regular network traffic and Double-Take traffic on a machine with multiple IP addresses.

    The IP address used on the source will be determined through the Windows route table.

     

    Snapshots

    

    A snapshot is an image of the source replica data on the target taken at a single point in time. You can failover to a snapshot. However, you cannot access the snapshot to recover specific files or folders.

    Turn on Enable scheduled snapshots if you want Double-Take to take snapshots automatically at set intervals.

    • Take snapshots on this interval—Specify the interval (in days, hours, or minutes) for taking snapshots.
    • Begin immediately—Select this option if you want to start taking snapshots immediately after the protection job is established.
    • Begin at this time—Select this option if you want to start taking snapshots starting at a later date and time. Specify the date and time parameters to indicate when you want to start.

    See Managing snapshots for details on taking manual snapshots and deleting snapshots.

    You may want to set the size limit on how much space snapshots can use. See your VSS documentation for more details.

    If your target is a cluster, snapshots will be lost when node ownership changes. However, Double-Take will take an automatic snapshot after a new node becomes owner, so there is always at least one snapshot you can failover to.

     

    Compression

    

    To help reduce the amount of bandwidth needed to transmit Double-Take data, compression allows you to compress data prior to transmitting it across the network. In a WAN environment this provides optimal use of your network resources. If compression is enabled, the data is compressed before it is transmitted from the source. When the target receives the compressed data, it decompresses it and then writes it to disk. You can set the level from Minimum to Maximum to suit your needs.

    Keep in mind that the process of compressing data impacts processor usage on the source. If you notice an impact on performance while compression is enabled in your environment, either adjust to a lower level of compression, or leave compression disabled. Use the following guidelines to determine whether you should enable compression.

    • If data is being queued on the source at any time, consider enabling compression.
    • If the server CPU utilization is averaging over 85%, be cautious about enabling compression.
    • The higher the level of compression, the higher the CPU utilization will be.
    • Do not enable compression if most of the data is inherently compressed. Many image (.jpg, .gif) and media (.wmv, .mp3, .mpg) files, for example, are already compressed. Some images files, such as .bmp and .tif, are decompressed, so enabling compression would be beneficial for those types.
    • Compression may improve performance even in high-bandwidth environments.
    • Do not enable compression in conjunction with a WAN Accelerator. Use one or the other to compress Double-Take data.

    All jobs from a single source connected to the same IP address on a target will share the same compression configuration.

     

    Bandwidth

    

    Bandwidth limitations are available to restrict the amount of network bandwidth used for Double-Take data transmissions. When a bandwidth limit is specified, Double-Take never exceeds that allotted amount. The bandwidth not in use by Double-Take is available for all other network traffic.

    All jobs from a single source connected to the same IP address on a target will share the same bandwidth configuration.

    The scheduled option is not available in clustered environments.

     

    • Do not limit bandwidth—Double-Take will transmit data using 100% bandwidth availability.
    • Use a fixed limit—Double-Take will transmit data using a limited, fixed bandwidth. Select a Preset bandwidth limit rate from the common bandwidth limit values. The Bandwidth field will automatically update to the bytes per second value for your selected bandwidth. This is the maximum amount of data that will be transmitted per second. If desired, modify the bandwidth using a bytes per second value. The minimum limit should be 3500 bytes per second.
    • Use scheduled limits—Double-Take will transmit data using a dynamic bandwidth based on the schedule you configure. Bandwidth will not be limited during unscheduled times.
      • New—Click New to create a new scheduled bandwidth limit. Specify the following information.
      • Daytime entry—Select this option if the start and end times of the bandwidth window occur in the same day (between 12:01 AM and midnight). The start time must occur before the end time.
      • Overnight entry—Select this option if the bandwidth window begins on one day and continues past midnight into the next day. The start time must be later than the end time, for example 6 PM to 6 AM.
      • Day—Enter the day on which the bandwidth limiting should occur. You can pick a specific day of the week, Weekdays to have the limiting occur Monday through Friday, Weekends to have the limiting occur Saturday and Sunday, or Every day to have the limiting repeat on all days of the week.
      • Start time—Enter the time to begin bandwidth limiting.
      • End time—Enter the time to end bandwidth limiting.
      • Preset bandwidth—Select a bandwidth limit rate from the common bandwidth limit values. The Bandwidth field will automatically update to the bytes per second value for your select bandwidth.
      • Bandwidth—If desired, modify the bandwidth using a bytes per second value. The minimum limit should be 3500 bytes per second.
      • Edit—Click Edit to modify an existing scheduled bandwidth limit.
      • Delete—Click Delete to remove a scheduled bandwidth limit.

      If you change your job option from Use scheduled limits to Do not limit bandwidth or Use a fixed limit, any schedule that you created will be preserved. That schedule will be reused if you change your job option back to Use scheduled limits.

      You can manually override a schedule after a job is established by selecting Other Job Options, Set Bandwidth. If you select No bandwidth limit or Fixed bandwidth limit, that manual override will be used until you go back to your schedule by selecting Other Job Options, Set Bandwidth, Scheduled bandwidth limit. For example, if your job is configured to use a daytime limit, you would be limited during the day, but not at night. But if you override that, your override setting will continue both day and night, until you go back to your schedule. See the Managing and controlling jobs section for your job type for more information on the Other Job Options.

       

11. Click Next to continue.

12. Double-Take validates that your source and target are compatible. The Summary page displays your options and validation items.

    Errors are designated by a white X inside a red circle. Warnings are designated by a black exclamation point (!) inside a yellow triangle. A successful validation is designated by a white checkmark inside a green circle. You can sort the list by the icon to see errors, warnings, or successful validations together. Click on any of the validation items to see details. You must correct any errors before you can enable protection. Depending on the error, you may be able to click Fix or Fix All and let Double-Take correct the problem for you. For those errors that Double-Take cannot correct automatically, you will need to modify the source or target to correct the error, or you can select a different target. You must revalidate the selected servers, by clicking Recheck, until the validation check passes without errors.

    Before a job is created, the results of the validation checks are logged to the Double-Take Management Service log on the target.

13. Once your servers have passed validation and you are ready to establish protection, click Finish, and you will automatically be taken to the Manage Jobs page.

Once protection is established, Double-Take monitors the virtual disks of the protected virtual machine for changes to the disk layout. If a new virtual hard disk is added to the virtual machine, the protection job will automatically be updated to include the new virtual hard disk, and a file difference mirror will automatically start. However, if a virtual hard disk is removed from the protected virtual machine, the virtual hard disk will not be removed from the projection job until it is deleted from the source or the protection job is deleted and re-created.

If your source is a cluster and the Double-Take service on the source is stopped and restarted but failover is not initiated, you will need to manually bring the supporting cluster resource back online through the cluster manager in order for your agentless Hyper-V job to reconnect and transition to a good state. The resource is located on the source cluster and is called DTTargetRes_VM_GUID, where VM is the name of your virtual machine and GUID is a global unique ID assigned to the job. The resource will be located in the Other Resources group.

If your source is a cluster and your cluster resource moves to a node that Double-Take considers a bad node (for example, the Double-Take service is not running or the node has an invalid activation code), your job will enter an error state. You must fix the issue on the cluster node and then you can restart the job. However, if this situation occurs on a target cluster, the job will no longer appear in the console. In this case, you will need to fix the issue on the cluster node and then bring the supporting cluster resource back online through the cluster manager. The resource is located on the source cluster and is called DTTargetRes_VM_GUID, where VM is the name of your virtual machine and GUID is a global unique ID assigned to the job. The resource will be located in the Other Resources group.

Related Topics