Any virtual machines deployed in a Tintri VMstore can be protected with Tintri’s SnapVM, CloneVM, and ReplicateVM features. System wide default settings can be used to protect all the virtual machines deployed on a VMstore. Adjust your VMstores’ settings (see figure 4-1).
Figure 4-1 – Tintri VMstore protection settings.
However, no two virtual machine systems may require the same schedule and protection. To protect a virtual machine with different protection requirements, right click on the virtual machine and select Protect (see figure 4-2). Tintri VMstores allow each VM to be protected using separate protection policies. This gives a virtualization administrator the added flexibility and granularity in protecting virtual machines with
different requirements. In the Protect window, a virtualization administrator can determine the local and remote retention policies of the snapshot on a per virtual machine basis.
Figure 4-2 – Using Tintri’s SnapVM, CloneVM and ReplicateVM to protect virtual machines.
Recovering Virtual Machines from Tintri VMstores
To restore your Hyper-V virtual machines, Windows PowerShell and Tintri Automation Toolkit version 1.0.3.1 or later is required. The Tintri Automation Toolkit must be installed on the Hyper-V server that has access to the Tintri VMstore. To restore a virtual machine into a standalone Hyper-V environment, you must write a restore script that utilizes Tintri PowerShell commands and Windows Hyper-V import-vm command. Figure 4-3 is a sample script. The script below is provided as is (see Appendix B) and require customization based on environmental needs. It is strongly recommended that you customize and test the scripts for use in in your Hyper-V environment.
Figure 4-3 – Restore-tintrivm script using Windows PowerShell and Tintri’s PowerShell Toolkit.
When attempting to restore a virtual machine that is fully configured with virtual switches and network definitions into a different Hyper-V environment, the import-vm from CLI could fail with the following error (see figure 4-4):
Figure 4-4 – import-vm failed
The configuration error could be caused by a failure to find the original Ethernet switch definition in the new DR Hyper-V environment. Tintri recommends using the following Microsoft solution to resolve the issue from CLI before another import-vm attempt.
DO: Use Tintri’s PowerShell toolkit to create powerful automated scripts to manage your Hyper-V virtual datacenter.
The sample script is a guide and it does not work as-is in another Hyper-V environment. You can use this guide to write and test your own restore scripts in your Hyper-V environment.
DO: Review the Microsoft import-vm documentation for additional parameter details.
DO: Tintri recommends using the following Microsoft import-vm documentation to resolve import-vm issue from CLI before another import-vm attempt.
If the import-vm is attempted from the Hyper-V Manager UI (see figure 4-5), the Hyper-V Administrator can manually update the connection and import the virtual machine into the DR Hyper-V environment.
Figure 4-5 – import-vm failed from Hyper-V Manager UI
To restore a virtual machine into a Hyper-V Failover Cluster, you must install the Tintri PowerShell Toolkit on the Hyper-V nodes in the Hyper-V Cluster. Installing the Tintri PowerShell Toolkit on the Hyper-V nodes will allow the Hyper-V Administrator to run Tintri PowerShell Toolkit from any of the Hyper-V nodes. When a virtual machine is restored from the Hyper-V server, the virtual machine will show up in SCVMM with Unsupported VM Configuration (see figure 4-6). The virtual hard disk path must be updated from the Hyper-V server before the virtual machine can be started in a SCVMM environment.
Figure 4-6 – Restored VM shows up in SCVMM as Unsupported VM Configuration
From the Hyper-V server, select the restored virtual machine from the Hyper-V Manager UI. Select the virtual machine settings and remove the ‘hyperv’ path from the virtual hard disk paths and save the virtual machine settings (see figure 4-7). Updating the virtual hard disk path is only required when attempting to restore a virtual machine into a Hyper-V Failover Cluster with SCVMM. This is because Tintri VMstore file shares are created as \\TintrVMstore\newfileshare. The main mount point \\TintriVMstore\hyperv\ is ignored in SCVMM.
Figure 4-7 – Remove ‘hyperv’ path from the virtual hard disk of the restored virtual machine
The updated virtual machine hard disk settings with ‘hyperv’ path removed should look like the example in figure 4-8. Click Apply and OK to save your changes for the restored virtual machine.
From the SCVMM manager, refresh the virtual machines on the Hyper-V node in the Hyper-V Cluster (see figure 4-9).
Figure 4-9 – Refresh Virtual Machines on the Hyper-V node from SCVMM
The restored virtual machine should show up in the VMs and Services of the SCVMM virtual machine view. It is Tintri’s recommendation to use the Migrate Storage Wizard in SCVMM and select Automatically place all VHDs with the configuration for the restored virtual machine to simplify the management of the restored virtual machine’s VHDs with the configuration in the DR Hyper-V environment (see figure 4-9).
Figure 4-9 – Migrate Storage Wizard
DO: It is Tintri’s recommendation to use the Migrate Storage Wizard in SCVMM and select Automatically place all VHDs with the configuration for the restored virtual machine to simplify the management of the restored virtual machine’s VHDs with the configuration in the DR Hyper-V environment.