0 0

Tintri VMstore™ with Microsoft Hyper-V Best Practice Guide

Introduction

This document provides best practice guidelines for using Tintri VMstore storage systems with standalone and clustered Hyper-V servers. Starting with the release of Windows Hyper-V Server 2012 R2, Microsoft recommends the use of SMB 3.0 file shares for deploying virtual machines and templates. The SMB 3.0 stack on the Tintri VMstore is specifically designed for the Hyper-V Server with storage features that are necessary for enterprise deployments of virtual machines.

  • Supports Hyper-V Failover Clustering and Virtual Machine High Availability (HA)

  • Integrates with the Microsoft SCVMM and Hyper-V Manager tools

  • Supports Offloaded Data Transfers (ODX) technology for native Fast File copies

  • Features Tintri per-VM snapshots, cloning, restores, and performance isolation 

  • Integrates with the Microsoft Hyper-V Server VSS framework

In summary, Tintri integrates powerful per-VM data management tools with native Hyper-V file shares to provide the most complete enterprise storage solution for deploying Hyper-V virtual machines.

Intended Audience

This best practice guide assists individuals who are deploying Microsoft Hyper-V Servers with the Tintri VMstore. Prior knowledge of Hyper-V virtualization, Active Directory best practices, and Ethernet networks will help in understanding the recommendations covered in this best practice guide.

Vendor Guidelines

The following guidelines are referenced when deploying Microsoft Hyper-V Server 2012 R2 virtualization with Tintri VMstores. The recommendations in this guide are meant to be used with a fully functioning deployment of Hyper-V Servers with Tintri.

NOTE: Tintri documentation is downloaded from the Tintri support portal at https://support.tintri.com and the Microsoft TechNet library is located at https://technet.microsoft.com.

Tintri VMstore Guides

  • Tintri VMstore All Flash/Hybrid System Administration Manual

  • SCVMM & Hyper-V Setup Guide

  • Tintri VMstore T800 and T5000 Series Reference Guides

Microsoft Hyper-V Server and SCVMM Guides

  • Microsoft TechNet Library – Windows Server 2012 Library

  • Microsoft TechNet Library – System Center 2012 Library

 

Consolidated List of Best Practices

The table below includes the recommended practices in this document. Click the text on any of the recommendations to jump to the section that corresponds to each recommendation for additional information.


DO: Use different subnets to separate the VMstore Admin, Data and Replication Networks. DO: Ensure that all servers and switches are configured with the same jumbo frame settings. DO: Use SMB 3.0 multichannel only with a small number of Hyper-V servers.

DO: Use NIC Teaming and LACP for the Hyper-V servers.

DO: Use LACP across switches to provide high availability for the admin and data networks.

DO: Use Microsoft’s best practices for Active Directory Domain Services.

DO: Ensure that Tintri VMstores are time synchronized with the Hyper-V servers and Domain Controllers.

DO: Keep access to the hyperv share restricted to administrators only.

DO NOT: Use the hyperv file share to store VMs.

DO: Allow SCVMM to manage the file shares on the VMstore.

DO: Make full use of Offloaded Data Transfer Technology (ODX) by using VMstore file shares for template libraries and SCVMM Library Shares.

DO: Use a file share size that matches the capacty of the VMstore.

DO: Create VMstore file shares specifically to be used as SCVMM Library Shares.

DO: Use UNC paths when specifying the default folders for storing VMs and VHDs.

DO: Set the size of the SCVMM file share to the effective capacity of the VMstore model. DO: Use Windows 2012 Dynamic VHDX format disks with VMs on VMstores.

DO: Install the latest integration services on all virtual machines.

DO: Locate VM Configuration Files and Virtual Hard Disks together for ease of management. DO: Use the VMstore to provide highly available storage for Hyper-V Failover Clusters.


 

Network Best Practices for Hyper-V and the Tintri VMstore

The Tintri VMstore provides highly available shared storage for use as Hyper-V file shares. The file shares on the VMstore are presented via the SMB 3.0 protocol, which is recommended by Microsoft for storing and sharing configuration, virtual hard disk (VHD) files and template libraries.

Figure 1 highlights the separate networks for management and storage. The Hyper-V management tools communicate with the VMstore via the management and data networks, and the Hyper-V Servers connect with file shares on the VMstore via the data network.

Network overview
Figure 1 – network overview

The Ethernet network used by the Microsoft Hyper-V Servers and the Tintri VMstores should be architected to avoid single points of failure. The following table summarizes the best practices for creating a highly available network with Hyper-V and the VMstore.

Network Technology Hyper-V Server Ethernet Switch VMstore
NIC Teaming recommended

 

n/a n/a
Multichannel optional n/a optional
LACP recommended recommended recommended
Jumbo Frames recommended recommended recommended
1 GbE Network Management Network Management Network Admin Network
10 GbE Data Network Data Network Data Network

Figure 2 - network recommendations

Tintri VMstore Network Interfaces

The Tintri VMstore has multiple hardware redundancies to ensure high availability. Each VMstore has two physical controllers deployed in an active/standby configuration. Each controller has separate Ethernet ports which are used to create the following networks.

  • Admin Network - Dual 1GbE ports for VMstore management

  • Data Network - Dual 10GbE ports for data access*

  • Replication Network - Optional separate dual 1GbE or 10GbE ports for replication

If a controller fails, or if a network interface in the active controller fails, the standby controller will seamlessly take over operation of the management and data networks. The virtual machines on the Hyper-V servers will continue to run without disruption. This seamless failover is also used during Tintri OS upgrades where failover between controllers is performed manually.

*NOTE: the Tintri VMstore model T820 comes standard with 1GbE network ports for the data network. Optional 10GbE network cards are available. All other VMstore models come with 10GbE standard.

Subnets

The VMstore Admin Network, Data Network and Replication Network should use different subnets to isolate the network traffic.


DO: Use different subnets to separate the VMstore Admin, Data and Replication Networks.



Jumbo Frames

The Tintri VMstore supports Ethernet jumbo frames which can be employed to improve the performance of large data transfers over the Data Network. If jumbo frames are deployed then the VMstore, network switches, and the Hyper-V servers must all be configured with the same jumbo frame settings. Erroneous mismatches between jumbo frame settings can result in poor performance and network connectivity issues. Refer to the VMstore Admin guide for information on diagnosing jumbo frame mismatches.


DO: Ensure that all servers and switches are configured with the same jumbo frame settings.



Multichannel

SMB 3.0 multichannel support is provided by the Tintri VMstore. This feature of SMB 3.0 enables the use of multiple TCP connections to aggregate Data Network bandwidth between the Hyper-V server and the Tintri VMstore.

Tintri recommends using multichannel when the VM workload demands the aggregate throughput of multiple 10GbE connections, and then only with a small number of Hyper-V servers.


DO: Use SMB 3.0 multichannel only with a small number of Hyper-V servers.


 

NIC Teaming and LACP with Hyper-V Servers

Multiple physical Ethernet network adapters on a Hyper-V server can be combined into a NIC team that provides fault tolerance in the event of a network adapter failure. Two NIC teaming connection modes are possible with Hyper-V – switch dependent and switch independent – along with two options for the switch dependent connection mode.

  • Dynamic Teaming via LACP (Link Aggregation Control Protocol) 

  • Static Teaming is where you configure it on the switch.

Tintri recommends using NIC Teaming and LACP with Hyper-V servers.


DO: Use NIC Teaming and LACP for the Hyper-V servers.



LACP with the VMstore

The VMstore supports static and dynamic link aggregation on the Ethernet ports used for the Admin Network and the Data Network. The VMstore supports a maximum of 2 ports per bond and does not support mixed Ethernet link speeds in same bond.

Tintri recommends using LACP with the VMstore to provide network redundancy across two network switches.


DO: Use LACP across switches to provide high availability for the admin and data networks.



Active Directory and DNS

A properly configured deployment of Hyper-V servers and Tintri VMstores requires highly available access to a common Microsoft Active Directory infrastructure. Virtual deployments of these servers is possible as long as Microsoft’s best practices are followed.

Microsoft cautions against creating single points of failure when deploying virtual domain controllers. In particular Microsoft recommends running at least two virtualized domain controllers per domain, located on different virtualization servers. This reduces the risk of losing access to the DC if a single server fails.


DO: Use Microsoft’s best practices for Active Directory Domain Services.



NTP Servers

Hyper-V deployments are sensitive to time differences between servers and it is strongly recommended that all Hyper-V servers, the Domain Controllers, and VMstores be kept time synchronized. Virtualized time sources should be avoided. An excellent source of NTP server pools is available at pool.ntp.org.


DO: Ensure that Tintri VMstores are time synchronized with the Hyper-V servers and Domain Controllers.



VMstore and SMB 3.0 File Shares

Windows Hyper-V 2012 R2 supports the use of SMB 3.0 file shares for VMs (configuration files and disks) and VM templates. There are two methods of creating Hyper-V file shares – via SCVMM or via PowerShell cmdlets.

NOTE: SCVMM does not support nested file shares and neither does the VMstore.
 

The Special File Share “hyperv”

The file share “hyperv” is a special share on the VMstore. This share is the root directory for all Hyper-V file shares on the VMstore. Access to this share is restricted to administrators by default. Keep access restricted and do not use this share to store VMs.


DO: Keep access to the hyperv share restricted to administrators only.

DO NOT: Use the hyperv file share to store VMs.



File Share Naming Conventions

The VMstore supports 200 file shares and the file share names cannot include any of the following reserved characters.

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

 

SCVMM Managed and Unmanaged File Shares

SMB 3.0 file shares are seen by SCVMM as either Managed file shares or Unmanaged file shares. SCVMM has full control over Managed file shares, but no control over Unmanaged file shares. When using SCVMM to manage Hyper-V servers Tintri recommends allowing SCVMM to manage the file shares on the VMstore.


DO: Allow SCVMM to manage the file shares on the VMstore.


 

Offloaded Data Transfer Technology (ODX)

Microsoft ODX - Offloaded Data Transfer - offloads file copy and movement commands from a Hyper-V server to a storage array that supports the ODX offload commands. Hyper-V will attempt to use ODX commands whenever it moves or copies files.

A great way to make use of ODX technology is by using a VMstore file share for VM storage and another file share on the same VMstore as a template library or SCVMM Library Share. That way ODX technology will be employed every time a VM Administrator deploys a template or copies a file from the template library, or SCVMM Library Share, to the VM folders. ODX technology is also triggered when File Explorer is used to copy files from one VMstore file share to another.

NOTE: Currently ODX technology works within a single VMstore and not between VMstores.


DO: Make full use of Offloaded Data Transfer Technology (ODX) by using VMstore file shares for template libraries and SCVMM Library Shares.



Viewing ODX Technology Offload to the VMstore

ODX technology shows up as “Fast File Copies” in SCVMM job details. Figure 3 shows a 20GB VM deployed in seconds using Tintri ODX offload technology as seen in “1.2 Deploy file (using Fast FileCopy)”.

a 20GB VHDX file deployed in seconds using ODX file copy offload technology
Figure 3 – a 20GB VHDX file deployed in seconds using ODX file copy offload technology
 

VMstore File Share and VM Limits

The VMstore has the following file share and VM limits.

  • Hard Limit of 200 file shares per VMstore.

  • Suggested Limit of 1000 VMs per file share.

 

Managing VMstore File Shares via SCVMM

SCVMM creates and manages SMB 3.0 file shares on the VMstore through SCVMM wizards. After configuring the VMstore as a Storage Provider then three SCVMM wizards are used to create and manage file shares. The following table shows the relevant Wizards.

SCVMM Wizard Action
Add Storage Devices Add the VMstore as an SCVMM recognized Storage Device. This step is required before file shares can be created or deleted.
Create File Share Wizard Creates a new SCVMM Managed file share on the VMstore.
Delete File Share Deletes a file share from the VMstore.
Hyper-V Properties > File Share Storage Configures the Hyper-V server to point to a VMstore file share when deploying VMs.
Add Library Shares Creates a Library Share on a VMstore file share.

Figure 4 – SCVMM wizards
 

Best Practices for the Add Storage Devices Wizard

Goal: Use the “Add Storage Devices Wizard” to add the VMstore as a Storage Device to SCVMM

SCVMM Wizard: SCVMM > Fabric > Storage > Providers > Add Storage Devices

NOTE: In addition to adding the Tintri VMstore as a managed storage device, the SCVMM “Add Storage Devices” wizard will also register all existing Hyper-V file shares on the VMstore. Tintri Recommends allowing SCVMM to manage all of the Hyper-V file shares on the VMstore.

Summary of the Best Practices and Recommendations for the “Add Storage Devices” Wizard

Wizard Field Recommendation / Best Practice
Select Provider Type SAN and NAS devices discovered and managed by a SMI-S provider.
Protocol SMI-S CIM-XML.
Provider IP address or FQDN FQDN of the VMstore admin port.
Run As account An Active Directory user account that has been assigned the Service Account role on the VMstore.
Select storage pools to place under management and assign a classification
  • All existing Storage Devices (file shares) will be imported.
  • Select the file shares that you want SCVMM to manage.
  • Assign a classification to the file shares managed by SCVMM.

Figure 5 – recommendations for the Add Storage Devices wizard in SCVMM

 

Best Practices for the Create File Share Wizard

Goal: Create a new file share on the Tintri VMstore

SCVMM Wizard: SCVMM > Fabric > Storage > File Servers > right-click > Create File Share

Summary of the Best Practices and Recommendations for the “Create File Share” Wizard

Wizard Field Recommendation / Best Practice
File server The name of the VMstore.
Storage type User defined value.
Storage pool User defined value.
Classification User defined value.
Size (MB) Enter the size of the VMstore in MB. The section titled “VMstore Capacity Reporting in SCVMM” contains a list of recommended values for this field.

Figure 6 – recommendations for the Create File Share wizard in SCVMM


DO: Use a file share size that matches the capacty of the VMstore.



Best Practices for Adding File Share Storage to the Hyper-V Servers

Goal: Configure the file share storage so the Hyper-V servers can use the VMstore when deploying VMs.

SCVMM Wizard: SCVMM > VMs and Services > name of cluster, server, or server group > right-click > properties > File Share Storage > Add...

Summary of the Best Practices and Recommendations for the “File Share Storage” menu

Menu Field Recommendation / Best Practice
File share path Pick from the list of SCVMM managed file shares, or enter the UNC path to an unmanaged file share.
Run As account Recommend using the default value. This field should already be populated with the name of an Active Directory user account that has been assigned the Service Account role on the VMstore.
Figure 7 – recommendations for the Add File Share Storage wizard in SCVMM
 
 

Using a VMstore File Share as an SCVMM Library Share

The SCVMM library is a catalog of VM resources that can be leveraged when creating new virtual machines and new virtual hard disks. The library stores virtual hard disks, virtual floppy disks, ISO images, scripts, driver files and application packages.

When a new VM is created from a resource in a library share, the Hyper-V server actually makes a copy of the resource from the library to the folder that contains the new VM. If the library share and target folder are both located on the VMstore then the Hyper-V server will use the ODX file copy offload engine on the VMstore to copy the files. The ODX technology uses the Fast File Copy feature of the VMstore to significantly reduce the time needed to create the new VM.

It is a best practice to store library resources separately from production VMs. Tintri recommends creating file shares on the VMstore specifically to be used as Library Shares.
 

Creating a Library Share

During the initial setup of SCVMM a single library server and a single library share are automatically configured on the SCVMM server. Once the SCVMM console contains a Windows server as an SCVMM library server, then the VMstore file shares can be added to the SCVMM library server and used as Library Shares.

The SCVMM “Add Library Shares” wizard will be pre-populated with all of the file servers and file shares that SCVMM is currently managing. If this menu doesn’t include the file shares on the VMstore, double- check that the VMstore has been added as a Storage Provider, and that the file shares are managed by SCVMM.

According to Microsoft, when you remove a library server or library share from SCVMM, Hyper-V does not delete files from the file system. The files in the file share remain on the VMstore.


DO: Create VMstore file shares specifically to be used as SCVMM Library Shares.


 

Managing VMstore File Shares via PowerShell Cmdlets

In Hyper-V deployments where SCVMM is not deployed, SMB 3.0 file shares are created and managed via Tintri PowerShell cmdlets. The following table shows the relevant PowerShell cmdlets.

PowerShell Cmdlet Action
Connect-TintriServer Establishes a session with the Tintri VMstore.
Get-TintriSmbShare Retrieves the SMB shares on the Tintri VMstore.
New-TintriSmbShare Creates a new Hyper-V SMB share.
Remove-TintriSmbShare Deletes a Hyper-V SMB share.
Get-TintriSmbShareAccess Retrieves the access control list (ACL) of the SMB share.
Grant-TintriSmbShareAccess Grants access to the SMB share.
Revoke-TintriSmbShareAccess Removes the specified access control entry from an SMB share.

Figure 8 – Tintri PowerShell cmdlets
 

Create File Shares on the VMstore via PowerShell Cmdlets

Use Tintri PowerShell cmdlets to create file shares on the VMstore. Run these cmdlets from a Hyper-V server, or any Windows system which can connect to the VMstore hostname on the VMstore Admin Network, and connect to the VMstore. The PowerShell commands are documented in the “Tintri Automation Toolkit Quick Start & Overview Guide”.

Connect-TintriServer Establish a session with the Tintri VMstore New-TintriSmbShare Create a new Hyper-V SMB file share Grant-TintriSmbShareAccess Grant the Hyper-V server access to the file share
 

Configure the Default Folders on the Hyper-V Server

Use Hyper-V Manager to set the default folders for storing Virtual Hard Disk files and Virtual Machines. The Hyper-V Settings menu is accessed from the Hyper-V Manager console by right-clicking the name of the Hyper-V Server.

Virtual Hard Disks Set to a UNC path of a file share on the VMstore

Virtual Machines Set to a UNC path of a file share on the VMstore

Tintri strongly recommends using UNC paths when specifying the default folders used to store VMs and VHDX files. Do not use mapped network drives as they can be dropped or remapped. A remapped network drive could lead to Hyper-V virtual machine errors.


DO: Use UNC paths when specifying the default folders for storing VMs and VHDs.


 

VMstore Capacity Reporting in SCVMM

SCVMM only reports capacity of block storage devices and does not request capacity from SMB 3.0 file shares. Instead of reporting on the actual capacity of an SMB 3.0 file share, SCVMM reports 0 GB. This explains why SCVMM reports the capacity of a Tintri VMstore as 0 GB.

Notes on the Total Capacity field of the SCVMM File Servers report:

  • The Total and Available capacity of a VMstore Storage Device is reported as 0 GB

  • The Total Capacity for a file share is set in SCVMM when the file share is created. 

  • When a file share capacity is set to zero MB then the Total Capacity is reported as 8,589,934,592.00 GB. (64 bits minus 1)

Tintri recommends setting the size of each file share to match the effective capacity of the VMstore model. When creating a SCVMM file share enter the value from the “Recommended Hyper-V Share Size (MB)” column from the following table into the “Size (MB)” field located in the SCVMM File Share wizard.

VMstore Model Effective Capacity Recommended Hyper-V Share Size (MB) Resulting Hyper-V Share Size (MB)
T5040 18 TB 18,432,000 18000000
T5060 36 TB 36,864,000 36000000
T5080 73 TB 74,752,000 73000000
T820 23 TB 23,552,000 23000000
T850 66 TB 67,584,000 66000000
T880 100 TB 102,400,000 100000000

Figure 9 – recommended Hyper-V file share size in MB


DO: Set the size of the SCVMM file share to the effective capacity of the VMstore model.


 

Hyper-V Virtual Machines Hyper-V

VM Generation Support

Windows Hyper-V Server 2012 R2 provides two generations of VMs – Generation 1 and Generation 2. Tintri supports both Generation 1 and Generation 2 VMs.

Supported Virtual Hard Disk Formats

Microsoft Hyper-V 2012 R2 supports two types of virtual hard disk formats – VHD and VHDX. The VHD format is a legacy format which was improved with the VHDX format that was released with Hyper-V 2012. Either format can be deployed with the Tintri VMstore.

Tintri supports all three types of VHD and VHDX format disks.

Fixed virtual hard disk: fixed virtual disks are also known as thick provisioned disks for when the virtual disk is created it is zeroed out to the full size of the allocation. The creation of this type of disk takes time as the storage underneath the virtual hard disk is zeroed out. With this type of disk the amount of storage consumed on the array is the amount allocated, not the amount of data stored on disk. This results in large amount of storage being zeroed out but not being used to store data.

Dynamic virtual hard disk: dynamic virtual disks are also know as thin provisioned disks for when the virtual disk is created it is not zeroed out. The actual storage consumed by the Dynamic virtual hard disk is very small (4MB with VHDX) and storage is consumed only as data is written to the virtual hard disk. Thus the amount of array storage consumed is the actual amound of data stored in each virtual disk, not the amount allocated.

Differencing virtual hard disk: the virtual disk is actually a child disk that is linked to a parent disk. This disk type deploys quickly, starts out very small, and grows only when data is updated. They can grow over time, protentially growing larger than the parent disk as security patches, updates, and fixes are applied. Therefore this disk type is used most often with VDI deployments where quick deployment of 1000s of VMs is needed, and the life of the VM is relatively short.

The fixed virtual hard disk format was once recommended as the only disk to be used with performance sensitive applications. There was concern that the performance of a Dynamic disk on hard disk drive technology would suffer with the Dynamic format because the disk and files would become fragmented over time. HDD technology does not provide good random I/O performance and fragmentation is a concern. But when Fixed virtual hard disk format is used, the entire size of the virtual disk is pre-allocated and thus consumes space on the HDD storage, whether the disk contains data or not. This can lead to consuming HDD storage that is never actually used to store data.

The Tintri VMstore is extremely good at random I/O. Testing shows that Dynamic format disks now perform as fast as Fixed format disks when deployed on Tintri. Dynamic format virtual disks can be deployed to take advantage of the space savings they offer.


DO: Use Windows 2012 Dynamic VHDX format disks with VMs on VMstores.


 

 

Tintri Recommendations for Windows Server 2008 VHD Format Disks

Disk Type Supported Max Size Recommendation
Fixed VHD Y 2040 GB Consumes 100% of the allocated space.
Dynamic VHD Y 2040 GB Supported. Provides space savings.
Differencing VHD Y 2040 GB High space savings.
Shared VHD N 2040 GB Not Supported.

Figure 10 – VHD disk types and recommendations
 

Tintri Recommendations for Windows Server 2012 VHDX Format Disks

Disk Type Supported Max Size Recommendation
Fixed VHDX Y 64TB Consumes 100% of the allocated space.
Dynamic VHDX Y 64TB Recommended. Provides space savings and performance similar to the Fixed VHDX.
Differencing VHDX Y 64TB High space savings.
Shared VHDX N 64TB Not Supported.

Figure 11 – VHDX disk types and recommendations
 

Integration Services

Hyper-V integration services are installed into a virtual machine to improve the performance and manageability of a VM running on Hyper-V. Integration services are available for Microsoft Windows and Linux OS. Tintri recommends using the latest version of the Integration Services with all VMs running with a VMstore.

The following essential services are provided for Windows and Linux VMs:

  • Operating system shutdown

  • Time synchronization

  • Data Exchange

  • Heartbeat

  • Backup (VSS)

  • Guest Services


DO: Install the latest integration services on all virtual machines.


 

Creating and Deploying New Virtual Machines

There are four ways to create and deploy Virtual Machines with Hyper-V, including System Center Virtual Machine Manager (SCVMM), Hyper-V Manager, Failover Cluster Manager, and PowerShell cmdlets.

While all management tools can be used to create and manage VMs, Failover Cluster Manager is the only tool that can create a Clustered (HA) VM. It can also be used to convert an existing non-HA VM to the Clustered configuration. Both Clustered VMs and non-Clustered VMs can be deployed successfully on the VMstore.

Tool Create VMs Manage VMs Create Clustered VMs Manage Clustered VMs
SCVMM yes yes yes yes
Failover Cluster Manager yes yes yes yes
Hyper-V Manager yes yes   yes
PowerShell Cmdlets yes yes yes yes

Figure 12 – Hyper-V management tools
 

Placement of VMs on the VMstore

Hyper-V has the option of storing the VM configuration files together with, or separately from, the Virtual Hard Disks. The VMstore will work effectively with both VM configurations.


DO: Locate VM Configuration Files and Virtual Hard Disks together for ease of management.



Using Templates to Create VMs

Templates can be used to create new VMs. The templates can be stored in SCVMM Library shares and in folders accessible by Hyper-V Manager. When the source files and the new VM are both located on VMstore file shares then ODX Fast File Copy technology will be automatically triggered copying the template files.

Tintri recommends using the VMstore for VM deployment, for use as SCVMM Library shares, and for file shares that can be accessed by the Hyper-V Manager. This way every time a VM is created from an existing VM or template then ODX File Copy Offload will be triggered.

 

Deleting VMs and Virtual Disks

All Hyper-V management tools – SCVMM, Hyper-V Manager, Failover Cluster Manager, PowerShell cmdlets - can be used to remove VMs. This action deletes the VM configuration files and unregisters the VM from the management tool. However, Microsoft has designed Hyper-V so that the “Remove” action only disconnects virtual disks and does not delete the files.

If necessary, the Windows Explorer, the DEL command, or the Remove-Item PowerShell cmdlet can be used to delete the files.
 

Hyper-V and Failover Clustering

A Hyper-V Failover Cluster is a group of Hyper-V Servers that work together to increase the availability of individual Virtual Machines. If a server were to fail then VM will be restarted – aka failover – to another server. Keep in mind that users will experience a short disruption as the VM fails over to another Hyper-V server and is restarted. Failover Clusters can scale up to a maximum of 64 Hyper-V servers. The VMstore provides the correct highly available storage to support VMs running in a Hyper-V Failover Cluster.

Hyper-V Failover Clusters are different from Guest Clustering. Hyper-V Clusters provides high availability for individual VMs, Guest Clustering provides HA for individual applications that run within the VM.

Guest Clustering is configured with two and only two VMs. Each VM has the ability to run the application so that one VM can take over the application if the other VM were to fail. Guest Clustering is based on sharing the virtual disk between two active VMs.

The VMstore does not support shared virtual disks or VM clustering that relies on shared virtual disks.


DO: Use the VMstore to provide highly available storage for Hyper-V Failover Clusters.



Tintri Snapshots

VMstore snapshots are the basis for the data management tools that are used to clone, restore and replicate Virtual Machines.

The VMstore supports two types of VM snapshots – VM-Consistent and Crash-Consistent. The VM- Consistent snapshots freeze and quiesce the I/O to the application and to the VM itself before taking a snapshot on the VMstore. Crash-Consistent snapshots are created without freezing I/O to the VM or application running in the VM.

NOTE: Installing the Tintri Hyper-V Services (THS) on each Hyper-V server installs the services required to integrate the VMstore with the VSS framework on each Hyper-V server.

 

Tintri VM Clones

Tintri VM clones are created quickly and consume almost no space until data in the VM is changed. Because the VMstore is Hyper-V aware newly cloned VMs are automatically added to the Hyper-V Manager and Failover Cluster Manager tools. SCVMM must be manually refreshed to update the display as seen in figure 13.

Refresh menu
Figure 13 – the Refresh Virtual Machines menu in SCVMM

Temporary_css