SIRIS, ALTO, and NAS: Virtualize via Hypervisor for Hyper-V environments

Topic

This article describes how to connect a Datto SIRIS to a Hyper-V hypervisor and running a virtualization via hypervisor offload. These instructions apply to virtual and physical SIRIS appliances.

For vSphere instructions, see SIRIS, ALTO, and NAS: Virtualize via Hypervisor for VMware environments.

Environment

• Datto SIRIS
• Microsoft Hyper-V
• Windows Server 2012R2
• Windows Server 2016

Description

• Purpose
• Technical Notes
• Configuring Hyper-V
• Troubleshooting
• Setting up the Hypervisor Connection
• Performing a Hyper-V Restore

Purpose

Datto SIRIS appliances can establish connections to Hyper-V environments to offload screenshot and disaster recovery virtualizations to the hypervisor. This connection allows the virtualizations to take advantage of the expanded system resources available on the Hyper-V host, delivering increased virtual machine performance, while decreasing overhead on your Datto appliance.

Datto SIRIS does not support taking agentless backups through the Hyper-V connection. Support for agentless pairings is limited to VMware environments only.

Technical Notes

• Hyper-V integration is supported on Windows Server 2012R2 and Windows Server 2016.
• SIRIS Hyper-V virtualizations are Hyper-V Generation 1 virtual machines.
• SIRIS shares out backup images for Hyper-V restores via iSCSI.
• Datto appliances do not currently support Hyper-V Shared Live Migration.
• iSCSI targets containing underscores (such as backup_device) are not supported.
• Virtualizations and screenshots offloaded to Hyper-V rely on virtual IDE controllers. This functionality limits virtualizations to a maximum of the boot volume and three attached disks.
• To prevent connections between your Datto appliance and the target hypervisor from being blocked, create any necessary network exceptions in your antivirus and firewall solutions before attempting this procedure.
• If your hypervisor is using Webroot anti-malware software, you will also need to create an exception for %systemdrive%\Windows\winexesvc.exe to prevent connections between the SIRIS and the protected system from being blocked.

Configuring Hyper-V

Depending on the configuration of your Hyper-V host, you may need to make changes to allow your SIRIS to connect to the hypervisor.

First attempt the steps described in the Auto-configuration through the Remote Service Management rule section of this article. If following the steps do not result in a successful hypervisor connection, follow the steps in the Enabling and configuring winrm and Windows Firewall section.

Auto-configuration through the Remote Service Management rule

Enabling this rule in Windows Firewall will allow your SIRIS to connect and create a hypervisor connection for screenshots and hypervisor virtualizations:

1. On the host, open the Windows Firewall with Advanced Security program.

2. Select Inbound Rules, and navigate to the Remote Service Management (NP-In) rule.

Figure 1: Remote Service Management (NP-In) (click to enlarge)

3. In the Actions sidebar, click Enable Rule.

Figure 2: Enable Rule (click to enlarge)

4. Proceed to the Setting up the Hypervisor Connection section of this article. If the setup fails, follow the steps in the Enabling and configuring winrm and Windows Firewall section.

Enabling and configuring winrm and Windows Firewall

Run the commands shown directly on the host.

NOTE: Setting up and configuring Hyper-V requires local administration rights. To set up Hyper-V as a domain account, follow this procedure, simulating local admin permissions. 

1. From an elevated Command Prompt session, run the winrm quickconfig command to enable remote management.

Figure 3: Enabling remote management (click to enlarge)

2. Enable basic authentication: winrm set winrm/config/service/auth @{Basic="true"}

Figure 4: Enabling basic authentication (click to enlarge)

3. Enable transfer of unencrypted data on the WinRM service:

winrm set winrm/config/service @{AllowUnencrypted="true"}

Figure 5: Enabling unencrypted data transfer (click to enlarge)

4. Create a new Inbound rule to allow TCP ports 139, 445, 5985, 5986, and 3260 through the Windows Firewall. These ports are for Samba, WinRM and iSCSI.

5. Launch the Windows Firewall with Advanced Security control panel, and select Inbound Rules → New Rule. In the New Inbound Rule Wizard, select Port, and click Next, as shown in Figure 6.

Figure 6: New Inbound Rule Wizard (click to enlarge)

6. Select TCP, and then select Specific local ports. Specify ports 139, 445, 5985, 5986, and 3260 for the forwarding rule, and click Next.

Figure 7: Configuring ports (click to enlarge)

7. Select Allow the connection on the Action tab, and click Next.

Figure 8: Allow the connection (click to enlarge)

8 Select Domain, Private, and Public on the Profile tab, and click Next.

Figure 9: Applying rule locations (click to enlarge)

9. Select a name for the new firewall rule, and Finish.

Figure 10: Rule name and description (click to enlarge)

Troubleshooting

Problem

When running the winrm quickconfig -q command, you receive output similar to the following:

C:\Users\ottad>winrm quickconfig -q
WinRM service is already running on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:
Configure LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.
WSManFault
    Message = Access is denied.
Error number:  -2147024891 0x80070005
Access is denied. 

Solution

According to Microsoft, local Administrator accounts other than the built-in Administrator account may not have rights to manage a server remotely, even if the production machine has remote management enabled.

You will need to configure the Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting to allow local Administrator accounts to manage the server remotely

To disable these restrictions, follow the below steps.

1. In the Windows Registry, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, and change the value of the LocalAccountTokenFilterPolicy key to 1.

2. If the LocalAccountTokenFilterPolicy entry does not exist, create a new DWORD Value called LocalAccountTokenFilterPolicy. Change the key's value to 1.

Problem

You are unable to add a Hyper-V connection to the Datto appliance using domain credentials, but you can add it without issue using local credentials.

Solution

This issue indicates that the domain administrator account does not have the correct permissions to manage Hyper-V hosts with Hyper-V Manager remotely. See this article (external link) for information about configuring a domain administrator account with Remote Management permissions.

Setting up the Hypervisor Connection

1. Access the GUI of your SIRIS over your LAN or through a Remote Web connection.

2. From the Datto appliance's Overview page, click Configure → Hypervisor Connections.

3. Click Add Connection.

Figure 11: Hypervisor connections screen (click to enlarge)

4. Enter a unique name for the new hypervisor connection, and the IP address, hostname, or FQDN of the Hyper-V host that the Datto appliance needs to connect to. Select Hyper-V from the Hypervisor Type menu.

Figure 12: Connection Name tab (click to enlarge)

5. On the Hypervisor Login tab, enter the credentials for a user that has the appropriate permissions to configure and control Hyper-V on your host. You will need the username and password, as well as the domain for the user (if applicable).

Figure 13: Hypervisor Login tab (click to enlarge)

Figure 14: Failed to execute command on host (click to enlarge)

6. If the wizard does not report any errors, click Finish to exit the Hypervisor Connection wizard.

Figure 15: Successful connection (click to enlarge)

The Datto appliance will return you to the Hypervisor Connections screen, where you will see the newly-added connection listed in the HyperV Connections pane. Click the radio button under Use for Screenshots if you would like the agent to use the resources of your hypervisor during screenshot verification.

Figure 16: Hyper-V screenshot offload option (click to enlarge)

Performing a Hyper-V Restore

When you create a hypervisor connection to your host, you can it to restore systems that are protected by your SIRIS appliance. To start, click the Restore tab at the top of the Datto appliance's GUI.

Figure 17: Restore tab (click to enlarge)

1. On the Restore tab, select the protected system that you want to restore to your Hyper-V server, and then select Virtualize via Hypervisor. Select the Recovery Point and the Hypervisor connection for the restore, and then click Start Virtualization.

Figure 18: Restore from a Backup (click to enlarge)

2. The virtualization settings page will load, and Datto appliance will automatically allocate the virtual machine's resources based on the OS type detected. You can make resource adjustments or add network adapters to the Virtual Machine directly from the Hyper-V Manager on your server.

Figure 19: Virtualization settings page (click to enlarge)

3. If you need to make modifications to the virtual machine, Datto recommends gracefully powering off the virtual machine from within the guest operating system. It is possible to stop the VM directly from the SIRIS UI, but this would be equivalent to a hard power-off instead of a graceful shutdown.

Figure 20: Shutting down a VM in Hyper-V (click to enlarge)

4. After making the resource changes, use Hyper-V Manager or the SIRIS UI to power the VM back on. In Figure 18, a technician increased the virtualization's core count from 1 to 4, provisioned 4 GB of RAM, and added a network adapter.

Figure 21: Modifying VM settings through Hyper-V (click to enlarge)

5. When you are finished using your restore, return to the SIRIS Restore tab and select Stop and Unmount. Note that this will destroy the Hyper-V virtualization, along with all changes made to it since the VM was first booted. If the virtual machine was in production, make sure you back up your changes before unmounting it.

Additional Resources

• Understanding and troubleshooting WinRM connection and authentication (external link)
• Test-WSMan: Tests whether the WinRM service is running on a local or remote computer (external link)
• Powershell Remoting (external link)