Dell EMC Unity Storage with Microsoft Hyper-V · PDF file2 Dell EMC Unity Storage with...

Dell EMC Best Practices

Dell EMC Unity Storage with Microsoft Hyper-V

All-flash arrays

Abstract

This white paper provides best practices guidance for configuring

Microsoft Hyper-V to perform optimally with Dell EMC Unity All-Flash

arrays.

July 2017

Revisions

2 Dell EMC Unity Storage with Microsoft Hyper-V | H16388

Revisions

Date Description

July 2017 Initial release for Dell EMC Unity OE version 4.2

Acknowledgements

This paper was produced by the following members of the Dell EMC storage engineering team:

Author: Marty Glaser

The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in this

publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any software described in this publication requires an applicable software license.

© 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other

trademarks may be trademarks of their respective owners.

Dell believes the information in this document is accurate as of its publication date. The information is subject to change without notice.

Table of contents


Table of contents

Revisions............................................................................................................................................................................. 2

Acknowledgements ............................................................................................................................................................. 2

Table of contents ................................................................................................................................................................ 3

Executive summary ............................................................................................................................................................. 5

Audience ............................................................................................................................................................................. 5

1 Introduction ................................................................................................................................................................... 6

1.1 Essential guidelines ............................................................................................................................................ 6

2 Storage configuration ................................................................................................................................................... 7

2.1 Dynamic storage pools ....................................................................................................................................... 7

3 Dell EMC Unity data services and features .................................................................................................................. 9

3.1 AppSync ............................................................................................................................................................. 9

3.2 FAST VP ............................................................................................................................................................. 9

3.3 FAST Cache ....................................................................................................................................................... 9

3.4 Compression ....................................................................................................................................................... 9

3.5 Snapshots ......................................................................................................................................................... 10

3.6 Asynchronous replication ................................................................................................................................. 11

3.7 Synchronous replication ................................................................................................................................... 12

3.8 Data at Rest Encryption (D@RE) ..................................................................................................................... 12

3.9 Host I/O Limits .................................................................................................................................................. 12

3.10 Dell EMC Storage Integrator for Windows Suite .............................................................................................. 13

4 Hyper-V with Dell EMC Unity overview ...................................................................................................................... 14

4.1 Hyper-V ............................................................................................................................................................. 14

4.2 Hyper-V with Dell EMC Unity ............................................................................................................................ 14

5 Optimize Hyper-V for Dell EMC Unity ........................................................................................................................ 15

5.1 Hyper-V general best practices ........................................................................................................................ 15

5.2 Hyper-V guest integration services................................................................................................................... 15

5.3 Hyper-V guest VM generations ........................................................................................................................ 17

5.4 Virtual hard disks .............................................................................................................................................. 18

5.5 Present Dell EMC Unity storage to Hyper-V .................................................................................................... 23

5.6 Offloaded Data Transfer (ODX) ........................................................................................................................ 28

5.7 Placement of page files .................................................................................................................................... 28

5.8 Dell EMC Unity data compression and Hyper-V .............................................................................................. 29

Table of contents


5.9 Placement of Active Directory Domain Controllers .......................................................................................... 29

5.10 Queue depth best practices for Windows Server Hyper-V ............................................................................... 29

6 Dell EMC Unity snapshots and thin clones with Hyper-V .......................................................................................... 31

6.1 Crash-consistent and application-consistent snapshots .................................................................................. 32

6.2 Using Dell EMC Unity snapshots to recover guest VMs .................................................................................. 32

6.3 Use Dell EMC Unity thin clones to create a test environment .......................................................................... 36

6.4 Leverage Dell EMC Unity to create gold images .............................................................................................. 36

6.5 Using Dell EMC Unity for Hyper-V VM migration ............................................................................................. 38

7 Boot from SAN for Hyper-V ........................................................................................................................................ 40

7.1 Boot from SAN advantages .............................................................................................................................. 40

7.2 When to use boot from local disk ..................................................................................................................... 40

7.3 Configure a Hyper-V host server to boot from SAN ......................................................................................... 40

8 Dell EMC Unity and NAS for Hyper-V ........................................................................................................................ 43

8.1 Configure Dell EMC Unity All-Flash array NAS server for Hyper-V ................................................................. 43

8.2 Create a file system on the NAS server to host SMB shares for Hyper-V ....................................................... 47

8.3 Access a Dell EMC Unity SMB share from a Hyper-V host server .................................................................. 51

8.4 Present Dell EMC Unity SMB file shares to Hyper-V clusters .......................................................................... 54

A Technical support and additional resources ............................................................................................................... 59

A.1 Related resources ............................................................................................................................................ 59

Executive summary


Executive summary

Microsoft® Hyper-V® and Dell EMC™ Unity storage are feature-rich solutions that together provide a diverse

range of configurations to solve key business objectives such as performance and resiliency.

This paper delivers straightforward guidance to customers deploying Hyper-V with Dell EMC Unity All-Flash

storage systems. It builds upon existing guidance for Hyper-V and Dell EMC Unity, which can be found in the

Dell EMC Unity Best Practices Guide as well as the documentation listed in appendix A.

This paper was developed using the Dell EMC Unity 350F All-Flash array, but the information herein is also

applicable to the 450F, 550F, and 650F models.

These best practices are strongly recommended by Dell EMC, but some recommendations may not apply to

all environments. For questions about the applicability of these guidelines in your environment, contact your

Dell EMC representative.

Audience

This document is intended for Dell EMC customers, partners, and employees who desire to learn more about

best practices when configuring Microsoft Hyper-V with Dell EMC Unity All-Flash storage systems. It assumes

the reader has working knowledge of Dell EMC Unity and Hyper-V.

We welcome your feedback along with any recommendations for improving this document. Send comments

to [email protected].

https://www.emc.com/collateral/white-papers/h15093-emc-unity-best-practices-guide.pdf

mailto:[email protected]

Introduction


1 Introduction Best practices are commonly used when organizations face design and configuration choices affecting the

cost, complexity, expandability, performance, availability, recoverably, and resiliency of the environment and

the workload. Due to numerous considerations such as these, a design that works well for one environment

may not be ideal for another — there is no one-size-fits-all answer. However, following best practices can

help you make informed choices that are best suited to your environment and ensure the best return on your

investment.

Much of the guidance in this document is focused on the best design for building a new solution. In many

cases, legacy systems that are performing well and have not reached their life expectancy may not be able to

follow current best practices. For example, using Hyper-V pass-through disks with generation 1 guest VMs for

guest clustering is considered a legacy design, compared to the use of shared virtual hard disks with

Microsoft Windows Server® 2016 Hyper-V today. Often, the best course of action is to run legacy

configurations until they reach their life expectancy because it might be too disruptive or costly to make

changes outside of a normal hardware progression or upgrade cycle.

While many administrators choose to continue running legacy configurations, Dell EMC recommends

upgrading to the latest technologies and adopting current best practices at key opportunities such as when

upgrading or replacing infrastructure.

1.1 Essential guidelines Dell EMC Unity and Hyper-V environments should follow established best practices and adhere to the

following essential guidelines:

Minimize complexity to ease administrative overhead.

Ensure redundancies for critical workloads to protect against single points of failure.

Ensure that DR recovery time and recovery point objectives (RTO/RPO) goals can be achieved.

Leverage the latest features in current Dell EMC Unity operating environment and Hyper-V versions.

Evaluate the solution in a test environment before deploying in production where possible.

Avoid or minimize the use of legacy hardware or software that have been deprecated or will be soon.

Avoid proprietary hardware or software that might limit future expansion, upgrades, or migration.

Allow for scalability to accommodate anticipated growth and other business needs over the expected

life of the hardware.

Storage configuration


2 Storage configuration Dell EMC Unity arrays provide a unified block and file storage platform for the ultimate experience in

simplicity, performance, and efficiency to meet a wide range of business needs.

Beginning with Dell EMC Unity Operating Environment (OE) version 4.2, the Dell EMC Unity All-Flash array

product line was expanded with 4 new models. While this guide features the Dell EMC Unity 350F model, the

information is also applicable to the 450F, 550F, and 650F models. For additional information on these

models, see the Dell EMC Unity All Flash Storage specification sheet.

This section addresses general storage recommendations and best practices for Dell EMC Unity All-Flash

arrays. For more best practices information, see the Dell EMC Unity Best Practices Guide and the additional

documentation listed in appendix A.

2.1 Dynamic storage pools The Dell EMC Unity All-Flash arrays leverage dynamic storage pools in addition to traditional storage pools.

Dynamic pools apply RAID to groups of drive extents created from drives within the pool and allow for greater

flexibility in managing and expanding the pool. Dynamic storage pools became available with Dell EMC Unity

OE version 4.2 and are only applicable to all-flash systems. For more information, see Dell EMC Unity:

Dynamic Pools at Dell EMC Support (login required).

In general, it is recommended to use a small number of pools within Dell EMC Unity to reduce complexity and

increase flexibility. However, it may be appropriate to configure multiple storage pools in order to:

Separate workloads with different I/O profiles

Separate pools where Dell EMC FAST™ Cache is and is not active (FAST Cache is not applicable to

all-flash arrays)

Dedicate resources to meet specific performance goals

Separate resources for multi-tenancy

Create smaller failure domains

2.1.1 Storage pool capacity Storage pool capacity is used for multiple purposes:

To store all data written into storage objects (LUNs, file systems, and datastores) in that pool

To store data which is needed for snapshots of storage objects in the pool

To track changes to replicated storage objects in that pool

To perform efficient data relocations for FAST VP (FAST VP is not applicable to all-flash arrays)

Storage pools must maintain free capacity in order to operate properly. By default, a Dell EMC Unity array will

raise an alert if a storage pool has less than 30% free capacity, and will begin to automatically invalidate

snapshots and replication sessions if the storage pool has less than 5% free capacity. Dell EMC recommends

that a storage pool always have at least 10% free capacity.

https://www.emc.com/collateral/data-sheet/h16018-unity-all-flash-family-ss.pdf


https://support.emc.com/

Storage configuration


2.1.2 RAID configurations Dell EMC Unity applies RAID protection to the drives in a storage pool in order to protect user data against

drive failures. Choose the RAID type that best suits your need for performance, protection, and cost:

RAID 1/0 provides the highest level of performance from a given set of drive resources, with the

lowest CPU requirements; however, only 50% of the total drive capacity is usable.

RAID 5 provides the best usable capacity from a set of drive resources, but at lower overall

performance and availability than RAID 1/0.

RAID 6 provides better availability than RAID 5 and better usable capacity than RAID 1/0, but has the

lowest performance potential of the three RAID types.

The RAID width for a dynamic pool is automatically chosen based on the number available drives in the pool.

Dell EMC generally recommends RAID 5 for drives in extreme performance and performance tiers, and RAID

6 for drives in the capacity tier. The performance and capacity tiers are only applicable to Dell EMC Unity

Hybrid systems. With Dell EMC Unity All-Flash arrays, tiering is not applicable and will not have performance

or capacity tiers.

2.1.3 All-flash pools All-flash pools provide the highest level of performance with Dell EMC Unity. Use an all-flash pool when the

application requires the highest storage performance at the lowest response time. Note the following

considerations with all-flash pools:

FAST Cache and FAST VP are not applicable to all-flash pools.

Compression is only supported in an all-flash pool.

Snapshots and replication operate most efficiently in all-flash pools.

Dell EMC recommends using only a single drive size and a single RAID width within an all-flash pool.

2.1.4 Hybrid pools Hybrid pools (including a combination of Flash drives and hard disk drives) are not supported with Dell EMC

Unity All-Flash arrays.

Dell EMC Unity data services and features


3 Dell EMC Unity data services and features This section includes best practices for Dell EMC Unity data services and features. Not all are applicable to

Dell EMC Unity All-Flash arrays. Find additional information on each of these features in the Dell EMC Unity

Best Practices Guide.

3.1 AppSync Dell EMC AppSync™ is software that enables Integrated Copy Data Management (iCDM) with Dell EMC

primary storage systems including Dell EMC Unity arrays.

AppSync simplifies and automates the process of creating and using copies of snapshots of production data.

By abstracting the underlying storage and replication technologies, and through application integration,

AppSync empowers application owners to manage data copy needs themselves. Storage administrators need

only be concerned with initial setup and policy management, resulting in a more agile environment.

Additional information on AppSync can be found in the AppSync User and Administration Guide and the

AppSync Performance and Scalability Guidelines.

3.2 FAST VP FAST VP accelerates performance of a specific storage pool by automatically moving data within that pool to

the appropriate drive technology, based on data access patterns. FAST VP is only applicable to hybrid pools

within a Dell EMC Unity Hybrid flash system and is therefore not applicable to all-flash arrays.

3.3 FAST Cache FAST Cache is a single global resource that can improve performance of one or more hybrid pools within a

Dell EMC Unity Hybrid flash system. FAST Cache can only be created with SAS Flash 2 drives, and is only

applicable to hybrid pools. FAST Cache is not applicable to all-flash arrays.

3.4 Compression Dell EMC Unity compression is available for block LUNs and VMFS datastores. With the release of Dell EMC

Unity OE version 4.2, NAS file systems and NFS datastores in an all-flash pool now support compression as

well.

For more information, see the Dell EMC Unity: Compression white paper located at Dell EMC Support (login

required).

While data compression helps to optimize storage investments by maximizing drive utilization, be aware that

data compression increases the overall CPU load on the Dell EMC Unity system when storage objects

service compressible data. This may result in increased latency which can negatively impact the performance

of a workload when it accesses compressed data.



https://support.emc.com/docu81036_AppSync-3.1-User-and-Administration-Guide.pdf?language=en_US

https://support.emc.com/docu43842_White-Paper:-AppSync-Performance-and-Scalability-Guidelines.pdf




Consider these best practices before enabling compression on a storage object such as a LUN:

Monitor the system to obtain pre-compression performance benchmarks.

Enable compression only if the storage system has available resources to support it.

Enable compression on a few storage objects at a time, and then monitor the system to be sure it is

still within recommended operating ranges, before enabling compression on more storage objects.

Consider that compression will be performed on a storage object only if the system determines that

the data is at least 25% compressible (else it remains uncompressed).

Do not enable compression on a storage object if it is known that there will be very little or no space

savings, which avoids consuming system resources unnecessarily.

Contact your Dell EMC representative for tools that can help analyze data compressibility.

For new storage object or storage objects that will be populated by migrating data from another source, it is

recommended to create the storage object with compression enabled, before writing any data. This provides

maximum space savings while minimizing system impact.

For existing storage objects that already contain data:

For minimal impact, enable compression and allow newly written data to be compressed as part of

the normal workload.

For maximum space savings, enable compression and use Compress Now to compress all existing

data.

- Use Compress Now only on one storage object per storage processor (SP) at a time.

- Where possible, run Compress Now during off-peak hours when the storage object is idle or

experiencing low workload.

- Only run Compress Now on a storage object if the storage pool has enough free capacity to

temporarily hold a second copy of the storage object.

3.5 Snapshots Dell EMC recommends including a flash tier in a hybrid pool where snapshots will be active. Since the focus

of this paper is on all-flash arrays, tiering is not applicable.

Consider the overhead of snapshots when planning for the performance and capacity requirements for the

storage pool. Be aware that snapshots increase the overall CPU load on the system and increase overall I/O

in the storage pool. Each new snapshot consumes a varying amount of pool capacity, depending on how

much data has changed since the last snapshot. Snapshots should not be retained any longer than is

needed. When older snapshots are deleted, the space consumed by them is returned to the pool.

Before enabling snapshots on a storage object, monitor the system to obtain benchmarks to ensure

that existing resources can meet the additional workload requirements.

Enable snapshots on a few storage objects at a time, and then monitor the system to be sure it is still

within the recommended operating ranges before enabling more snapshots.

Stagger snapshot operations such as creation and deletion. This can be accomplished by using

different snapshot schedules for different sets of storage objects.

For hybrid flash systems (not applicable to all-flash arrays), schedule snapshot operations to occur

after any FAST VP relocations have completed.



Snapshots are deleted by the system serially. When a snapshot is in the process of being deleted, its state is

reported by the system as Destroying. If there are more expired snapshots pending destruction than the

system can handle, they will accumulate in a queue, and this can negatively impact system performance.

Encountering this situation indicates that the existing snapshot schedules may be too aggressive. To alleviate

this issue, modify existing snapshot schedules to occur less frequently. To minimize the performance impact,

the system will throttle queued snapshot delete operations in favor of host I/O during regular or peak usage

times. Snapshot deletes will occur more quickly during periods of low system utilization when there are more

system resources available.

For more information on the configuration, management and functionality of snapshots and thin clones, see

the Dell EMC Unity: Snapshots and Thin Clones white paper located at Dell EMC Support (login required).

3.6 Asynchronous replication Dell EMC Unity All-Flash arrays are optimized for asynchronous replication due to the performance

advantages of Flash drives over spinning disks. For hybrid flash arrays, including a flash tier in a hybrid pool

where asynchronous replication will be active is recommended for both source and destination pools.

Asynchronous replication takes a point-in-time snapshot of a storage object configured for replication in order

to determine the data that has changed since the last update. Only the data that has changed is replicated, so

the process is automatically optimized for efficiency. This also maintains consistency during the data transfer.

Note the following best practices:

Consider the overhead of snapshots when planning performance and capacity requirements for a

storage pool which will have replication objects.

Configure replication only on storage objects that need it.

Segregate data to different storage objects so that data that does not need replication is not grouped

with data that does. This will reduce the amount of data being replicated.

For replication to remote locations, make sure there is enough bandwidth and latency performance on

WAN links to allow asynchronous replications to complete without negatively impacting other

resources that might compete for the same WAN bandwidth.

Configuring more frequent snapshots of a storage object for shorter RPO will not result in quicker data

transfers. It will result in many more snapshot operations, which can negatively impact system performance. If

performance is a concern, take snapshots less frequently if a longer RPO is acceptable, or manually

synchronize during non-peak hours.

For more information on replication with Dell EMC Unity, see the Dell EMC Unity: Replication Technologies

white paper at Dell EMC Support (login required).





3.7 Synchronous replication Dell EMC Unity All-Flash arrays are also optimized for synchronous replication due to the performance

advantages of Flash drives over spinning disks. For hybrid flash arrays, including a flash tier in a hybrid pool

where synchronous replication will be active is also recommended for both source and destination pools.

The best practices listed in section 3.6 for asynchronous replication also apply to synchronous replication.

Synchronous replication transfers data to the remote system using FC ports on the SPs in this order:

When the CNA ports are configured as FC, the lowest numbered FC CNA port is designated as the

replication port. Consider limiting the number of host connections using this port if performance or

available bandwidth is a concern.

If the CNA ports are configured for a transport other than FC, replication will use the lowest numbered

FC I/O Module port as the replication port (FC Port 0) and therefore a 4-port FC module is required.

For more information on replication, see the Dell EMC Unity: Replication Technologies white paper at Dell

EMC Support (login required).

3.8 Data at Rest Encryption (D@RE) D@RE is controller-based encryption that does not impact performance. Dell EMC recommends ordering

Unity systems as encryption-enabled if appropriate for your environment.

Note: Encryption can only be enabled at the time of system installation with the appropriate license.

If encryption is enabled, Dell EMC recommends making external backups of the encryption keys after system

installation, as well as immediately following any change in the system’s drive configuration (such as creating

or expanding a storage pool, adding new drives, or replacing a faulted drive).

For more information on D@RE, see the Dell EMC Unity: Data at Rest Encryption white paper at Dell EMC

Support (login required).

3.9 Host I/O Limits Dell EMC recommends configuring Host I/O limits in cases where a workload might inadvertently monopolize

shared system resources to ensure that other workloads are not negatively impacted.

Example: Limit the bandwidth available to large-block applications which may be increasing the

latency on other small-block workloads.

Additional information can be found in the Dell EMC Unity: Unisphere Overview white paper at Dell EMC










3.10 Dell EMC Storage Integrator for Windows Suite The Dell EMC Storage Integrator (ESI) for Windows Suite is a set of tools for Microsoft Windows (including

Hyper-V) and Microsoft applications administrators. The suite includes:

ESI for Windows and the ESI PowerShell Toolkit

ESI system adapters

ESI hypervisor support

ESI Service and the ESI Service PowerShell Toolkit

ESI SCOM Management Packs

The toolkits are written for the PowerShell platform, which is developed by Microsoft specifically for Windows

System Management automation.

To learn more about Dell EMC ESI, see the Dell EMC Storage Integrator for Windows Suite Product Guide at

Dell EMC Support (login required).


Hyper-V with Dell EMC Unity overview


4 Hyper-V with Dell EMC Unity overview

4.1 Hyper-V The Windows Server platform leverages Hyper-V for virtualization technology. Initially offered with Windows

Server 2008, Hyper-V has matured with each release to include many new features and enhancements. With

the release of Windows Server 2016, Hyper-V is also supported on Nano Server in addition to Server Core

and Server with Desktop.

Microsoft Hyper-V has evolved to become a mature, robust, proven virtualization platform. At a basic level, it

is a layer of software that presents the physical host server hardware resources in an optimized and

virtualized manner to one or more guest virtual machines (VMs). Hyper-V hosts (also referred to as nodes

when clustered) can greatly enhance utilization of physical hardware (such as processors, memory, NICs,

and power supplies) by allowing many VMs to share these resources at the same time. Hyper-V Manager and

related management tools such as Failover Cluster Manager, Microsoft System Center Virtual Machine

Manager (SCVMM), and PowerShell, offer administrators great control and flexibility for managing host and

VM resources.

Many core Hyper-V features (such as dynamic memory) are storage agnostic, and are not covered in detail in

this guide. To learn more about Hyper-V features, functionality, and general best practices, see the Hyper-V

Best Practices Checklist and other resources on Microsoft TechNet.

4.2 Hyper-V with Dell EMC Unity Any discussion about Dell EMC Unity All-Flash arrays and Hyper-V best practices is going to center on the

storage — the actual LUNs and file shares that are presented to physical hosts and cluster nodes, along with

the virtual hard disks, pass-through disks, and direct-attached storage presented to VMs.

As a fully unified storage solution, Dell EMC Unity All-Flash arrays can be configured to present storage

through traditional SAN-based block storage utilizing Fibre Channel or iSCSI, and through file-based SMB file

shares to Hyper-V environments. In recent years, Microsoft has promoted the use of SMB as an alternative to

traditional block-based SAN storage. In cases where the infrastructure to support FC or iSCSI is already in

place, customers can continue to realize the return on their investment by using these robust transports with

Dell EMC Unity. SMB file shares can be used instead of, or concurrently with, FC and iSCSI. Small branch

offices present an attractive use case for SMB where the cost and complexity of FC or iSCSI networks,

fabrics, and infrastructure can be avoided.

Dell EMC Unity All-Flash arrays support SMB 3.1.1 and are compatible with Microsoft Windows Server 2008

R2 Hyper-V through Windows Server 2016 Hyper-V.

Many core Dell EMC Unity All-Flash array features such as thin provisioning, data compression, snapshots,

and replication work seamlessly in the background, regardless of the platform. In many cases, the default

settings for these features work well with Hyper-V or serve as good configuration starting points. This

document covers additional configuration or tuning steps to enhance performance, utilization, or resiliency.

https://blogs.technet.microsoft.com/askpfeplat/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form/

https://blogs.technet.microsoft.com/askpfeplat/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form/

https://technet.microsoft.com/library/default.aspx

Optimize Hyper-V for Dell EMC Unity


5 Optimize Hyper-V for Dell EMC Unity The following sections include additional configuration or tuning steps to enhance the performance, utilization,

and resiliency of Hyper-V with Dell EMC Unity.

5.1 Hyper-V general best practices There are many general best practices for Hyper-V not specific to storage that are not discussed in detail in

this document. See resources such as Microsoft TechNet for guidance on general Hyper-V best practices.

The following provides a high-level summary of common Hyper-V tuning steps:

Minimize or disable unnecessary hardware devices and services to free up CPU cycles that can be

used by other VMs (this also helps to reduce power consumption).

Schedule tasks such as periodic maintenance, backups, virus scans, and patching to run after hours,

and stagger start times when such operations overlap and are CPU or I/O intensive.

Tune application workloads to reduce or eliminate unnecessary processes or activity.

Leverage Microsoft PowerShell® or other scripting tools to automate step-intensive repeatable tasks

to ensure consistency and avoid human error (which also reduces administration time).

In addition to these general guidelines, the following subsections provide detailed configuration information.

5.2 Hyper-V guest integration services Guest integration services are a package of virtualization-aware drivers that are installed on a guest VM to

optimize the guest VM virtual hardware for interaction with the physical host hardware and storage. Installing

these drivers is typically the first step for optimizing VM performance. If a VM is not performing as expected

(due to CPU, disk I/O, or network performance), verify that the VM integration services are current.

Installing and updating integration services is one of the most commonly overlooked steps to ensure overall

stability and optimal performance of guest VMs. Although newer Windows-based OSs and some enterprise-

class Linux-based OSs come with integration services out of the box, updates may still be required. New

versions of integration services may become available as the physical hosts are patched and updated.

With earlier versions of Hyper-V (2012 R2 and prior), during the configuration and deployment of a new VM,

the configuration process does not prompt the user to install or update integration services. In addition, the

process to install integration services with older versions of Hyper-V (2012 R2 and prior) is a bit obscure and

will explained in this section. The good news is that with Windows Server 2016 Hyper-V, integration services

are now updated automatically (in the case of Windows VMs) as a part of Windows updates, requiring less

administration to ensure Windows VMs stay current.

One common issue occurs when VMs are migrated from an older physical host or cluster to a newer one (for

example, from Windows Server 2008 R2 Hyper-V to Windows Server 2012/R2 Hyper-V). The integration

services do not get updated automatically, and degraded performance may be encountered as a result.




Aside from performance problems, one of the key indications that integration services are outdated or not

present on a Windows VM is the presence of unknown devices in Device Manager for the VM.

Unknown guest VM devices can indicate missing or outdated integration services

For versions of Hyper-V prior to 2016, use Hyper-V Manager to connect to a VM. Under the Action menu,

mount the Integration Services Setup Disk (an ISO file), and follow the prompts in the guest VM console to

complete the installation. Mounting the integration services ISO is no longer supported with Windows Server

2016 Hyper-V because integration services are provided exclusively as part of Windows updates.

Mount Integration Services Setup Disk



To verify the version of integration services, under the Summary tab for each VM, select Failover Cluster

Manager.

Verify integration services version with Failover Cluster Manager

Verification can also be performed using PowerShell, as shown in the following example:

PS C:\Windows\system32> get-VM | Select-Object name, integrationservicesversion

Name IntegrationServicesVersion

---- -------------------------

MG-VM12a 6.3.9600.18080

MG-VM12b 6.3.9600.18080

MG-VM12c 6.3.9600.18080

MG-VM12d 6.3.9600.18080

5.3 Hyper-V guest VM generations The generation of a guest VM (generation 1 or generation 2) is an important part of the overall storage

strategy. When Windows Server 2012 R2 Hyper-V was released, Microsoft designated all existing VMs as

generation 1 to differentiate them from a new classification of VMs that could be created as generation 2.

Although generation 1 VMs continue to be supported with Hyper-V, it is a best practice to create new VMs as

generation 2 if the host server (Windows Server 2012 R2 Hyper-V and newer) and the guest VM OS support

it. Support for generation 1 VMs may eventually be depreciated in future versions of Hyper-V.



Generation 2 guests use Unified Extensible Firmware Interface (UEFI) when booting instead of a legacy

BIOS. UEFI provides better security and better interoperability between the OS and the hardware, which

offers improved virtual driver support and performance. In addition, one of the most significant changes with

generation 2 guests is the elimination of the dependency on virtual IDE for the boot disk. Generation 1 VMs

require the boot disk to use a virtual IDE disk controller. Generation 2 guests instead use virtual SCSI

controllers for all disks. Virtual IDE is not a supported option with generation 2 VMs.

Specify a guest as generation 1 or generation 2

For both generations of guest VMs, if there are multiple disks requiring high I/O, each disk can be associated

with its own virtual disk controller to further maximize performance.

5.3.1 Convert VMs to a newer generation Note the warning in Figure 4 that the VM generation cannot be changed once a VM has been created.

However, it is now possible to convert a VM from generation 1 to generation 2. While Microsoft has ongoing

efforts to provide tools to perform this action, third-party tools may be available currently (use at your own

risk). More information on this topic can be found on Microsoft TechNet.

5.4 Virtual hard disks A virtual hard disk is a set of data blocks that is stored as a regular Windows file with a .vhd, .vhdx, or .vhds

extension, using the host operating system. It is important to understand the different format and type options

for virtual hard disks and how this integrates with Dell EMC Unity All-Flash arrays.




5.4.1 Virtual hard disk format There are three different kinds of virtual hard disk formats that are supported with either VM generation:

VHD is supported with all Hyper-V versions and is limited to a maximum size of 2 TB. This is now

considered a legacy format (use VHDX instead for new VM deployments).

VHDX is supported with Windows Server 2012 Hyper-V and newer. The VHDX format offers better

resiliency in the event of a power loss, better performance, and supports a maximum size of 64 TB.

VHD files can be converted to the VHDX format using tools such as Hyper-V Manager or PowerShell.

VHDS (VHD Set) is supported on Windows Server 2016 Hyper-V and newer. VHDS is for virtual hard

disks that are shared by two or more guest VMs in support of highly-available (HA) guest VM

clustering configurations.

Virtual hard disk formats

5.4.2 Virtual hard disk type In addition to the format, a virtual hard disk can be designated as fixed, dynamically expanding, or

differencing.

Virtual hard disk types



The dynamically expanding disk type will work well for most workloads on Dell EMC Unity All-Flash arrays.

Since Dell EMC Unity arrays leverage thin provisioning, only data that is actually written to a virtual hard disk,

regardless of the disk type (fixed, dynamic, or differencing), will consume space on the array. As a result,

determining the best disk type is mostly a function of the workload as opposed to how it will impact storage

utilization. For workloads generating very high I/O, such as Microsoft SQL Server databases, Microsoft

recommends using the fixed size virtual hard disk type for optimal performance.

As shown in Figure 7, a fixed virtual hard disk consumes the full amount of space from the perspective of the

host server. For a dynamic virtual hard disk, the space consumed is equal to amount of data on the virtual

disk (plus some metadata overhead), and is more space efficient from the perspective of the host. From the

perspective of the guest VM, either type of virtual hard disk shown in this example will present a full 60 GB of

available space to the guest.

Fixed and dynamic virtual hard disk comparison

There are some performance and management best practices to keep in mind when choosing the right kind of

virtual hard disk type for your environment.

Fixed-size virtual hard disks:

- Are recommended for virtual hard disks that experience a high level of disk activity, such as

Microsoft SQL Server, Microsoft Exchange, or OS page or swap files. For many workloads, the

performance difference between fixed and dynamic will be negligible. When formatted, they take

up the full amount of space on the host server volume.

- Are less susceptible to fragmentation at the host level.

- Take longer to copy (for example, from one host server to another over the network) because the

file size is the same as the formatted size.

- With older versions of Hyper-V prior to 2012, provisioning of fixed virtual hard disks may require

significant time due to lack of native Offloaded Data Transfer (ODX) support. With Windows

Server 2012 and newer, provisioning time for fixed virtual hard disks is significantly reduced when

ODX is supported and enabled.



Dynamically expanding virtual hard disks:

- Are recommended for most virtual hard disks, except in cases of workloads with very high disk

I/O.

- Require slightly more CPU and I/O overhead because they grow compared to fixed virtual hard

disks. This usually does not impact the workload except in cases where I/O demand is very high.

This is minimized even further on Dell EMC Unity All-Flash arrays due the higher performance of

all-flash disk pools.

- Are more susceptible to fragmentation at the host level.

- Consume very little space (for some metadata) when initially formatted, and expand as new data

is written to them by the guest VM.

- Take less time to copy to other locations than a fixed disk because only the actual data is copied.

For example, a 500 GB dynamically expanding virtual hard disk that contains 20 GB of data will

copy in the amount of time it takes 20 GB of data to copy, not 500 GB.

- Allow the host server volume to be over-provisioned. In this case, it is an important best practice

to configure alerting on the host server to avoid running the volume out of space unintentionally.

Differencing virtual hard disks:

- Offer some storage savings by allowing multiple Hyper-V guest VMs with identical operating

systems share a common boot virtual hard disk.

- Require all children to use the same virtual hard disk format as the parent.

- Are referenced by reads of unchanged data. Unchanged data that is read infrequently may reside

in a lower classification of storage on systems that support tiering. With Dell EMC Unity All-Flash

array, all data resides in the same performance tier.

- Require new data to be written to the child virtual hard disk.

- Are created for each native Hyper-V based snapshot of a Hyper-V guest VM to freeze the

changed data since the last snapshot, and allow new data to be written to a new virtual hard disk

file. Creating native Hyper-V based snapshots of a Hyper-V guest VM can elevate the CPU usage

of storage I/O, but will probably not affect performance noticeably unless the guest VM

experiences very high I/O demands.

- Can result in performance impacts to the Hyper-V guest VM because maintaining a long chain of

native Hyper-V based snapshots of the guest VM requires reading from the virtual hard disk and

checking for the requested blocks in a chain of many different differencing virtual hard disks.

- Should not be used with native Hyper-V based snapshots of Hyper-V guests, or should be kept at

a minimum to maintain optimal disk I/O performance. With Dell EMC Unity, native Hyper-V

snapshots can be minimized or even avoided altogether by leveraging array-based storage

snapshots. Administrators can leverage array-based snapshots as a way to recover VMs and

replicate data to other locations for archive or recovery.

5.4.3 Virtual hard disks and thin provisioning with Unity All-Flash arrays It does not matter which type of virtual hard disk is used with regard to maximizing the space utilization on

Dell EMC Unity storage. Regardless of the virtual hard disk type, only the actual data written by a guest VM

will consume space on the storage array due to the advantages of thin provisioning.



The example shown in Figure 8 illustrates a Dell EMC Unity All-Flash 100 GB volume presented to a Hyper-V

host that contains two 60 GB virtual hard disks (overprovisioned in this case to demonstrate behavior, but not

as a best practice). One is fixed, and the other is dynamic. Each virtual hard disk contains 15 GB of actual

data. From the perspective of the host server, 75 GB of space is consumed.

Example: 60 GB fixed disk + 15 GB of used space on the dynamic disk = 75 GB total

Note: The host server reports the entire size of a fixed virtual hard disk as consumed.

Thin provisioning with Dell EMC Unity All-Flash array

Comparatively, this is how the Dell EMC Unity All-Flash array reports storage utilization on this same volume:

Example: 15 GB of used space on the fixed disk + 15 GB of used space on the dynamic disk = 30 GB

Note: Because of thin provisioning, regardless of the type of virtual hard disk, space on the Dell EMC Unity

All-Flash array is consumed only as actual data is written. Choosing dynamic over fixed virtual hard disks

does not improve storage space utilization on Dell EMC Unity arrays. Other factors such as the I/O

performance of the workload would be primary considerations when determining the type of virtual hard disk

in your environment.

5.4.4 Overprovisioning with dynamic virtual hard disks With dynamic virtual hard disks and thin provisioning, there is an inherent risk of either the host volume or a

storage pool on the Dell EMC Unity array running out of space. Figure 8 shows an example of this. If the

dynamic disk used by VM2 on the host volume expanded far enough, it would fill up the underlying host

volume and negatively impact both VM1 and VM2. From the perspective of VM2, it would still recognize

20 GB of free space, but would not be able to use it because the underlying physical host volume is full. To

resolve this, an administrator would need to move the virtual hard disk for VM1 or VM2 elsewhere to free up

space, or expand the 100 GB host volume. In either case, identifying the problem may not be obvious, and

resolving the problem might incur a service outage.



To mitigate risks, consider the following best practice recommendations:

Create a Hyper-V physical host volume that is large enough so that current and future expanding

dynamic virtual hard disks will not fill the host volume to capacity. Creating large Hyper-V host

volumes will not waste space on Dell EMC Unity All-Flash arrays because of thin provisioning.

- If Hyper-V based snapshots are used (which create differencing virtual hard disks on the same

physical volume), allow adequate overhead on the host volume for the extra space consumed by

the differencing virtual hard disks.

- Expand existing host volumes as needed to avoid the risks associated with overprovisioning.

- If a physical host volume that hosts virtual hard disks is overprovisioned, set up monitoring so that

if a percent-full threshold is exceeded (such as 90%), and an alert is generated with enough lead

time to allow for remediation.

Monitor alerts on Dell EMC Unity so that warnings about disk pool capacity thresholds are remediated

before a disk pool reaches capacity.

5.5 Present Dell EMC Unity storage to Hyper-V There are several different ways to present Dell EMC Unity All-Flash storage to Windows Server Hyper-V

hosts, nodes, and VMs. While this paper provides a brief overview, see the configuration guide, Configuring

Hosts to Access Fibre Channel (FC) or iSCSI Storage, for detailed guidance on configuring hosts to access

Fibre Channel or iSCSI volumes on Dell EMC Unity arrays.

Note the following points for presenting Dell EMC Unity storage to Hyper-V:

Boot from SAN is supported by all versions of physical Hyper-V hosts and nodes except for Nano

server, which requires local disk on the host for boot.

Dell EMC Unity storage can be presented to physical Hyper-V hosts and cluster nodes using Fibre

Channel, iSCSI, or SMB file shares.

Dell EMC Unity storage can also be presented directly to Hyper-V guest VMs using:

- In-guest iSCSI (referred to as direct-attached storage)

- Pass-through disks (Dell EMC and Microsoft strongly advise against using pass-through disks, a

legacy configuration, if possible)

- SMB file shares

5.5.1 Modify Windows host server file system attributes Formatting a large Dell EMC Unity volume mapped to a Windows host (this is not specific to the Hyper-V role)

should complete in a few seconds. If long format wait times are experienced for larger volumes (minutes

instead of seconds), disable the file system Delete Notify attribute on the host by completing the following

steps:

1. Access a command prompt on the host server with elevated (administrator) rights.

2. To verify the state of the attribute, type fsutil behavior query disabledeletenotify and press Enter.

A result of zero means the attribute is enabled.

3. To disable the attribute, type fsutil behavior set disabledeletenotify 1 and press Enter.

https://www.emc.com/collateral/TechnicalDocument/docu69325.pdf




The result should display an attribute value of one. To test the result, temporarily map a large Dell EMC Unity

volume (such as 2 TB) to the host and format the volume. It should now complete in a few seconds.

5.5.2 Transport options Dell EMC Unity All-Flash storage can be presented to Hyper-V environments using iSCSI or Fibre Channel,

and will typically include a multipath I/O (MPIO) configuration for load balancing and failover protection.

Typically, an environment is configured to use a preferred transport when it is built and will be part of the

infrastructure core design. When deploying Hyper-V to existing environments, the existing transport is

typically used. Deciding which transport to use is usually based on customer preference and factors such as

size of the environment, cost of the hardware, and the required support expertise.

It is not uncommon, especially in larger environments, to have more than one transport available. This might

be required to support collocated but diverse platforms with different transport requirements. When this is the

case, administrators might be able to choose between different transport options.

5.5.3 Dell EMC Unity support for front-end SAS Dell EMC Unity All-Flash arrays do not currently support front-end SAS connectivity to host servers.

5.5.4 Mixed transports Although Dell EMC Unity arrays support mixed transports, there is limited Microsoft support. For each LUN

mapped to a Hyper-V host or node, use either FC or iSCSI, but not both. Each transport by itself should

present adequate bandwidth and redundant paths that leverage MPIO. Using multiple transports increases

design complexity unnecessarily and can introduce unpredictable service-affecting I/O behavior in path failure

scenarios.

5.5.5 MPIO best practices The Windows Server operating system and Hyper-V (2008 and newer) natively support MPIO by means of

the built-in Device Specific Module (DSM) that is bundled with the OS. Although the basic functionally offered

with the Microsoft DSM is supported, Dell EMC recommends the use of Dell EMC PowerPath™ (licensed, at

additional cost) for MPIO management on server hosts and VMs instead of the Microsoft DSM. Dell EMC

PowerPath, a server-resident software solution designed to enhance performance and application availability,

provides the following:

Combines automatic load balancing, path failover, and multiple-path I/O capabilities into one

integrated package.

Enhances application availability by providing load balancing, automatic path failover, and recovery

functionality.

Supports servers, including cluster servers, connected to Dell EMC and third-party arrays.

For complete guidance on installing and configuring PowerPath including guidance for Windows Server

Hyper-V, see the PowerPath Installation and Administration Guide for Microsoft Windows at Dell EMC






For more information on MPIO setup, including changing registry values, see the Configuring Hosts to Access

Fibre Channel (FC) or iSCSI Storage white paper.

Windows and Hyper-V Hosts will default to Round Robin with Subset with Dell EMC Unity All-Flash storage,

unless a different default MPIO policy is set on the host by the administrator.

Verify MPIO settings (Microsoft DSM shown)

Note the following:

The active/optimized paths are associated with the Dell EMC Unity storage processor (SP) that owns

the volume. The active/unoptimized paths are associated with the other SP.

If each SP has 4 FC paths configured (as shown in the Figure 9 example), each volume that is

mapped should list 8 total FC paths: 4 that are optimized, and 4 that are unoptimized.

Best practices recommendations include:

Changes to MPIO registry settings for FC or iSCSI (such as time-out values) should not be made

unless directed by Dell EMC documentation (see Configuring Hosts to Access Fibre Channel (FC) or

iSCSI Storage) or as directed by Dell EMC to solve a specific problem.

Configure all available data ports on a Dell EMC Unity array to use your preferred transport (FC or

iSCSI) to optimize array CPU utilization and maximize performance.







Verify that current versions of software are installed (such as boot code, firmware, and drivers) for all

components in the data path:

- Dell EMC Unity OE

- Data switches

- Host bus adapters (HBAs), network interface cards (NICs), and converged network adapters

(CNAs)

Verify that all hardware is supported. See the Dell EMC Unity Simple Support Matrix (login required)

for software and hardware support information.

5.5.6 Guest VMs and in-guest iSCSI Dell EMC Unity supports in-guest iSCSI to present block storage volumes directly to guest VMs. The setup

and configuration are essentially the same as for a physical host server, except that the VM is using virtual

hardware.

5.5.7 Direct-attached in-guest iSCSI storage use cases Although Dell EMC Unity arrays support in-guest iSCSI volumes mapped to guest VMs, direct-attached

storage for guest VMs is generally not recommended as a best practice unless there is a specific use case

that requires it. Typical use cases include:

Situations where a workload has very high I/O requirements, and the performance gain over using a

virtual hard disk is important. Direct-attached disks bypass the host server file system. This reduces

host CPU overhead for managing guest VM I/O. For many workloads, there will be no notable

difference in performance between direct-attached and virtual hard disks with all-flash arrays.

VM clustering on legacy platforms prior to support for shared virtual hard disks, which became

available with the 2012 R2 release of Hyper-V, and enhanced with Hyper-V 2016.

When needing to troubleshoot I/O performance on a particular volume and it must be isolated from all

other servers and workloads.

When there is a need to create custom snapshot or replication policies or profiles on Dell EMC Unity

for a specific data volume.

When a single data volume presented to a guest VM will exceed the maximum size for a VHD (2 TB)

or VHDX (64 TB).

There are also some disadvantages to using direct-attached storage for guest VMs:

The ability to perform native Hyper-V snapshots is lost. However, the ability to leverage Dell EMC

Unity snapshots is unaffected.

Complexity increases, requiring more management overhead to support.

VM mobility is reduced due to creating a physical hardware layer dependency.

Note: Legacy environments that are using direct-attached disks for guest VM clustering should consider

switching to shared virtual hard disks, particularly if migrating to Windows Server 2016 Hyper-V.

https://elabnavigator.emc.com/vault/pdf/EMC_Unity_ESSM.pdf?key=1496639784237



5.5.8 Guest VMs and pass-through disks A block-based pass-through disk is a special type of Hyper-V disk that is mapped to a Hyper-V host or cluster,

and then is passed through directly to a Hyper-V guest VM. The Hyper-V host or cluster has visibility to a

pass-through disk but does not have I/O access. Hyper-V keeps it in a reserved state as only the guest VM

has I/O access.

Using pass-through disks is a legacy design that is strongly discouraged unless there is a specific use case

that requires it. They are no longer necessary in most cases because of the feature enhancements with

newer releases of Hyper-V (generation 2 guest VMs, VHDX format, and shared VHDs in Windows Server

2016 Hyper-V.) Use cases for pass-through disks are similar to the list provided for direct-attached iSCSI

storage in section 5.5.7.

Reasons to avoid using pass-through disks include:

The ability to perform native Hyper-V snapshots is lost, which is similar to direct-attached storage.

The use of a pass-through disk as a boot volume on a guest VM prevents the use of a differencing

disk.

VM mobility is reduced by creating a dependency on the physical layer.

This can result in a large number of LUNs presented to hosts or cluster nodes which can become

unmanageable and impractical at larger scale.

5.5.9 Dell EMC Unity and Hyper-V server clusters When mapping shared volumes (quorum disks, cluster disks, or cluster shared volumes) to multiple hosts,

make sure that the volume is mapped to all nodes in the cluster using a consistent LUN number.

At present, it is not possible to specify a specific LUN ID when mapping a volume to a host or node with Dell

EMC Unisphere™. Unisphere simply picks the next available free LUN ID for that host or node. This means

that if the next available LUN ID is not the same on all nodes in a cluster, the IDs will not be consistent. LUN

IDs can be changed in Unisphere after the volume is mapped if necessary.

As a best practice and a time-saving tip, configure the nodes in a cluster so that they are identical with regard

to the number of disks and LUNs. In this way, when mapping new storage LUNs, the next available LUN ID

will be the same on all hosts. By doing this, having to change LUN IDs after the fact to make them consistent

can be avoided.

5.5.10 Volume design considerations for Dell EMC Unity One of the design considerations for which there are often no clear answers is how many guest VMs to place

on a Dell EMC Unity volume, including cluster shared volumes (CSV) when clustered. While many-to-one and

one-to-one strategies both have advantages, a many-to-one strategy presents a good design starting point in

most scenarios, and can be adjusted for specific uses cases.

Some advantages for a many-to-one strategy include:

Fewer Dell EMC Unity array volumes to create and administer (avoids volume sprawl)

Quicker VM deployment because additional guest VMs do to not require creation of a new volume on

the Dell EMC Unity array



Some advantages for a one-to-one strategy include:

Easier to isolate and monitor disk I/O patterns for a specific Hyper-V guest VM

Ability to quickly restore a guest VM by simply recovering the Dell EMC Unity volume from a snapshot

Gives administrators more granular control over what data gets replicated, if Dell EMC Unity volumes

are replicated to another location

Makes it faster to move a guest VM from one host or cluster to another by remapping the volume

rather than copying large virtual hard disk files from one volume to another over the network

Other strategies might include placing all boot virtual hard disks on a common CSV, and data volumes on

other CSVs.

5.6 Offloaded Data Transfer (ODX) Offloaded Data Transfer (ODX) reduces CPU and network utilization on a host server by offloading a file-copy

process from the host server to the Dell EMC Unity array. This feature is supported in Hyper-V environments

with Windows Server 2012 and newer. ODX is enabled by default and it is a best practice to leave it enabled,

unless there is a need to obtain performance benchmarks or troubleshoot a problem.

ODX is also leveraged by SCVMM environments. Progress bars will indicate that a copy operation is a rapid

copy when ODX is being leveraged, for example, to deploy a new VM over the network from a template on

the SCVMM library server.

5.7 Placement of page files Windows Servers and VMs typically place the page file on the boot volume by default, and automatically

manage page file and memory settings without user intervention. In most cases, these settings should not be

changed, unless, for example, an application vendor provides specific guidance on how to tune the page file

and memory settings to optimize the performance of a particular workload. Ultimately, each customer will

need to decide on the best strategy as they consider variables that are unique to their environment.

With Dell EMC Unity, there can be some advantages to placing a page file on a separate volume from the

perspective of the storage array. The following reasons may not be sufficiently advantageous by themselves

to justify changing the defaults, but in cases where a vendor recommends making changes to optimize a

workload, consider the following tips as part of the overall page-file strategy.

Moving the page file to a separate dedicated volume reduces the amount of data that is changing on

the system (boot) volume. This can help reduce the size of Dell EMC Unity snapshots of boot

volumes which will conserve space in the disk pool.

Volumes or virtual hard disks dedicated to page files typically do not require snapshot protection, and

therefore do not need to be replicated to a remote site. This is especially beneficial in cases where

there is limited bandwidth for replication of volumes and snapshots to other Dell EMC Unity arrays.



5.8 Dell EMC Unity data compression and Hyper-V Data compression can be enabled (or disabled) on a volume-by-volume basis to increase storage efficiency.

Data compression with Hyper-V is fully supported with no special configuration required. Dell EMC Unity

volumes with data (such as video) that are already in a compressed format may not achieve much additional

space savings when compression is enabled.

For more information about compression, see the Dell EMC Unity: Compression Overview white paper at Dell

EMC Support (login required).

5.9 Placement of Active Directory Domain Controllers It is a best practice to avoid configuring a Microsoft Active Directory® (AD) domain controller as a Hyper-V

guest VM on a Hyper-V cluster when the cluster service requires AD authentication in order to start.

Consider this scenario: A service outage takes the cluster offline (including the domain controller VM). When

attempting to recover, unless there is another domain controller available outside of the affected cluster, the

cluster service will not start because it cannot authenticate.

Note: This order dependency can be avoided with Windows Server 2016 Hyper-V because the cluster service

uses certificates to authenticate instead of AD. With Windows Server 2016, Hyper-V clusters can also be

comprised of nodes that are in workgroups or domains.

Encountering this scenario may be a service-affecting event depending on how long it takes to recover. It may

be necessary to manually recover the domain controller VM to a standalone Hyper-V host outside of the

cluster, or to another cluster.

This situation can be avoided by doing the following:

Configure at least one domain controller as a physical server booting from local disk.

Place virtualized domain controllers on standalone Hyper-V hosts or on individual cluster nodes if

there is an AD dependency for cluster services.

Use Hyper-V Replica (2012 and newer) to ensure that the guest VM can be recovered on another

host.

Place virtualized backup domain controllers on separate clusters, so that a service-affecting event

with any one cluster does not result in all domain controllers becoming unavailable. This does not

protect against cases where there is a site outage that takes all the clusters (and therefore all the

virtualized AD servers) offline.

Leverage Windows Server 2016 Hyper-V, which does not have an AD dependency to authenticate

cluster services.

5.10 Queue depth best practices for Windows Server Hyper-V Queue depth is defined as the total number of disk transactions that are allowed to be in flight between an

initiator (a port on the host server) and a target (a port on the storage array). The initiator is typically a

Windows Server HBA FC port or iSCSI initiator, and the target is an FC or iSCSI port on the SAN array (in

this case, Dell EMC Unity). Since any given target port can have multiple initiator ports sending it data, the

https://support.emc.com/search/?text=unity%20white%20papers




initiator queue depth is generally used to throttle the number of transactions any given initiator can send to a

target from a host to keep the target from becoming flooded. When flooding happens, the transactions are

queued, which can cause higher latencies and degraded performance for the affected workloads.

5.10.1 When to change queue depth One question that is commonly asked is concerning best practices for queue depth settings for Windows

Server hosts and nodes with Hyper-V. On a Windows Server host, queue depth is a function of the Microsoft

storport.sys driver and the vendor-specific miniport driver for the FC HBA, iSCSI NIC, or CNA.

In many cases, there is no need to change the default queue depth, unless there is a specific use where

changing the queue depth is known to improve performance. For example, if a storage array is connected to a

small number of Windows Server Hyper-V cluster nodes hosting a large block sequential read application

workload, increasing the queue depth setting may be very beneficial. However, if the storage array has many

hosts all competing for a few target ports, increasing the queue depth on a few hosts might overdrive the

target ports and negatively impact the performance of all connected hosts.

While increasing the queue depth can sometimes increase performance significantly for specific workloads, if

it is set too high, there is an increased risk of overdriving the target ports on the storage array. Generally, if

transactions are being queued and performance is being impacted, and increasing the queue depth results in

saturation of the target ports, then increasing the number of initiators and targets to spread out I/O can be an

effective remediation.

5.10.2 Vendor-specific HBA and CNA queue depth settings It is very important to understand the firmware and miniport driver registry settings for your host server FC

HBA, iSCSI NIC, or CNA adapter and how these settings affect queue depth. In the case of QLogic® FC

HBAs for example, the execution throttle setting can be adjusted to control queue depth.

See the documentation for your particular FC HBA, iSCSI NIC, or CNA for direction on adjusting firmware or

registry settings to modify queue depth. For example, see this QLogic support article which explains in detail

the relationship between the Windows Server storport.sys driver and the vendor-specific miniport driver, and

how to modify parameters that affect queue depth by editing registry keys or firmware settings.

Note: Changes to FC HBA, iSCSI NIC, or CNA firmware or registry settings that affect queue depth should be

evaluated in a test environment prior to implementation on production workloads.

http://support.qlogic.com/SupportCenter/articles/Question_Answers/2718

Dell EMC Unity snapshots and thin clones with Hyper-V


6 Dell EMC Unity snapshots and thin clones with Hyper-V Dell EMC Unity snapshots can be used to protect any workload, including Hyper-V, on both block and file-

based storage resources. Because snapshots use the same technology for block and file, managing

snapshots is very similar between storage resource types. snapshots and thin clones can be created and

managed with Unisphere (GUI), from the command line (CLI), or by using the RESTful API.

Dell EMC Unity snapshots leverage redirect on write (ROW) which means that new writes to snapped storage

resources are written to a new location in the same disk pool. This space-efficient method uses metadata

pointers to direct I/O to new data that has changed since the last storage resource snapshot, while the frozen

data in snapshots is available if needed for recovery.

A thin clone is created from a snapshot, and is similar to a snapshot, except that a thin clone can be managed

like a fully independent LUN (with some limitations), and will look and act like an ordinary LUN to the host

server. A thin clone can have its own snapshot schedule and is very space efficient because it uses metadata

pointers to reference data from the source snapshot it was created from.

Thin clones support Dell EMC data services and features using Unisphere, the CLI, or RESTful API. In

addition, thin clones:

Can be mapped to a host as a regular LUN

Support the configuration of host I/O limits

Support snapshots and snapshot schedules

Can be added to LUN consistency groups

Support replication to other Dell EMC Unity arrays, along with their snapshot histories

For complete guidance on Dell EMC Unity snapshots and thin clones, see the Dell EMC Unity Snapshots and

Thin Clones white paper at Dell EMC Support (login required).

Dell EMC Unity point-in-time snapshots and thin clones allow administrators to do the following in Hyper-V

environments:

Recover servers to a crash-consistent state, including Hyper-V hosts (when using boot-from-SAN)

and guest VM workloads

Provision lab, parallel, or isolated test environments (thin clones)

Provision new servers from thin clones created from a gold image source snapshot

Point-in-time Dell EMC Unity snapshots can be taken of volumes regardless of content. This applies to boot-

from-SAN disks, data disks, cluster shared volumes containing virtual hard disks, pass-through disks, and

direct-attached in-guest iSCSI disks. Not only can snapshots be taken, but these disks and volumes and their

associated snapshots can be quickly and easily replicated to other Dell EMC Unity arrays for DR or other

purposes.




6.1 Crash-consistent and application-consistent snapshots Unless a server is powered off at the time a snapshot is taken, or first put into a consistent state (for example,

by leveraging the Microsoft volume shadow copy service (VSS) to gracefully pause a server or application),

Dell EMC Unity snapshots are considered to be crash consistent. When recovering a server using a crash-

consistent snapshot, it is similar to having the server recover from a power outage at that point in time. In

most cases, servers and applications are resilient enough to recover to a crash-consistent state without any

complications, whether the cause is an unexpected power outage, or the server is being recovered to a

previous point in time to recover from an event such as a malware infection. An exception to this is when the

Hyper-V environment hosts a transactional workload such as Microsoft Exchange or SQL Server®. With

transactional workloads, the risk of data corruption is higher when attempting to recover to a crash-consistent

state.

Some examples for how to configure and use Dell EMC Unity snapshots for a Hyper-V environment are

provided in the following sections.

6.2 Using Dell EMC Unity snapshots to recover guest VMs Hyper-V guest VMs can be recovered to a previous point in time by using crash-consistent Dell EMC Unity

snapshots. Thin clones can be used to create copies of VMs in an isolated environment at the same or a

different location when volume replication between Dell EMC Unity arrays used. This section provides

guidance and best practices for several different recovery options using snapshots.

6.2.1 Recover a guest VM on a standalone Hyper-V host In this scenario, the virtual hard disk and configuration files for a VM reside on a data volume that is mapped

to a Hyper-V host.

If a VM hard disk and configuration files reside on separate host data volumes, then it is a best practice to

configure a consistency group for these volumes so they are snapped at exactly the same time. For example,

a boot virtual hard disk for a VM might reside on one host volume, while one or more virtual hard disks for

data might reside on another volume. Database files may also span several Dell EMC Unity volumes.

When performing a recovery of a VM with Dell EMC Unity snapshots or thin clones, there are several options.

Option 1: Recover the existing data volume on the host that contains the VM configuration and virtual hard

disks by using a Dell EMC Unity snapshot. A thin clone can also be used to replace the existing volume by

using the same LUN number, drive letter mapping, or mount point.

This may only be practical if the data volume contains only one VM. If the data volume contains

multiple VMs, it will still work if all the VMs are being recovered to the same point in time. Otherwise,

option 2 or 3 would be necessary if needing to recover just one VM.

This will allow the VM being recovered to power up without any additional configuration or recovery

steps required.

It is essential to document the LUN number, disk letter, or mount point information for the volume to

be recovered, before starting the recovery.



Option 2: Map a snapshot or thin clone containing the VM configuration and virtual hard disks to the host as

a new volume, in a side-by-side fashion using a new drive letter or mount point. The VM can be recovered by

manually copying the virtual hard disks from the recovery snapshot or thin clone to the original location.

This involves deleting, moving, or renaming the original virtual hard disks.

After copying the recovered virtual hard disks to their original location, they must be renamed and

Hyper-V manager must be used to re-associate them with the guest VM. This is necessary to allow

the guest VM to start without permissions errors.

This may not be practical if the virtual hard disks are extremely large. In this case, the original VM can

be deleted, and the recovery VM imported (Hyper-V 2012 and newer) or created as a new VM

(Hyper-V 2008 R2) directly from the recovery volume. After the recovery, the original data volume can

be unmapped from the host if no longer needed.

This method also facilitates recovery of a subset of data from a VM by mounting a recovery virtual

hard disk as a volume on the host server temporarily.

Option 3: Map the recovery snapshot or thin clone to a different Hyper-V host and recover the VM there by

importing the VM configuration or creating a new VM that points to the virtual hard disks on the recovery

volume.

This is common in situations where the original VM and the recovery VM both need to be online at the

same time, but be isolated from each other to avoid name or IP conflicts, or split-brain with data

reads/writes.

This is also a great way to recover when the original host server is no longer available due to a host

failure.

If possible, before beginning any VM recovery, record essential details about the VM hardware configuration

(such as number of virtual CPUs, RAM, virtual networks, and IP addresses) in case importing a VM

configuration is not supported (Hyper-V 2008 R2) or fails.

6.2.2 Recover guest VM on a cluster shared volume The process of using Dell EMC Unity snapshots or thin clones to recover guest VMs that reside on a cluster

shared volume (CSV) is similar to the process of recovering a guest VM to a standalone host, as detailed in

section 6.2.1. However, recovering a VM from a snapshot or thin clone of a CSV may require changing the

disk signature first.

Windows servers assign each volume a unique disk ID (or signature). For example, the disk ID for an MBR

disk is an 8-character hexadecimal number such as 045C3E2F4. No two volumes mapped to a server can

have the same disk ID.

When a Dell EMC Unity snapshot or thin clone is taken of a Windows or Hyper-V volume, the snapshot is an

exact point-in-time copy, which includes the Windows disk ID. Therefore, recovery volumes created from

snapshots or thin clones will also have the same disk ID.

With standalone Windows or Hyper-V servers, disk ID conflicts are avoided because standalone servers are

able to automatically detect duplicate disk IDs and change them dynamically on the offending disk with no

user intervention.



However, host servers are not able to dynamically change conflicting disk IDs when disks are configured as

CSVs, because the disks are mapped to multiple nodes at the same time.

When attempting to map a copy (snapshot or thin clone) of a CSV back to any server in that same cluster, the

recovery volume will cause a disk ID conflict, which can be potentially service-affecting.

There are a couple of ways of working around the duplicate disk ID issue:

Option 1: Map the recovery volume containing the CSV to another host that is outside of the cluster and copy

the guest VM files over the network to recover the guest VM.

Option 2: Map the recovery volume to another Windows host outside of the cluster and use Diskpart.exe or

PowerShell to change the disk ID. Once the ID has been changed, remap the recovery volume to the cluster.

The steps to use Diskpart.exe to change the disk ID are detailed in section 6.2.3.

6.2.3 Change a cluster shared volume disk ID with Diskpart Follow these steps to change a volume disk ID. PowerShell can also be used.

1. Access the standalone Windows host that the recovery volume containing the CSV will be mapped to.

2. Open a command window with administrator rights.

3. Type diskpart.exe and press Enter.

4. Type list disk and press Enter.

5. Make note of the current list of disks (in this example, Disk 0, Disk 1, Disk 2).

6. Map the recovery volume containing the CSV to this host.

7. From the Diskpart command prompt, type rescan and press Enter.

8. Use Disk Management on the host server to bring the recovery volume online.



9. Return to the Diskpart command prompt window, type list disk, and press Enter.

The new disk (Disk 3 in this example) should now be listed. Usually, the bottom disk will be the one

just added.

10. Type select disk # (where # represents the number of the new disk, in this example, Disk 3) and

press Enter.

11. Type uniqueid disk and press Enter to view the current ID for the disk.

12. To change the disk ID, type uniqueid disk ID=<newid> and press Enter.

- For <newid>, provide a random ID of your choice. For an MBR disk, the new ID must be an 8-

character string in hexadecimal format using a mix of the numbers 0–9 and the letters A–F.

- For a GPT disk, the new ID must be a Globally Unique Identifier (GUID).

13. Type uniqueid disk again and press Enter to verify the ID is now changed.

Now that the disk has a new signature, it can be unmapped from the standalone host server and re-

mapped to the cluster without causing a disk ID conflict.

14. Recover the guest VM.



6.3 Use Dell EMC Unity thin clones to create a test environment In addition to VM recovery, Dell EMC Unity thin clones can be used to quickly create test or development

environments that mirror a production environment. When thin clones containing VMs are replicated to

another location, this makes it very easy to do this at a different location.

Note: To avoid IP, MAC address, or server name conflicts, copies of existing VMs that are brought online

should be isolated from the original VMs.

The procedure to use a thin clone to create a test environment from an existing Hyper-V guest VM is very

similar to VM recovery. The main difference is that the original VM continues operation, and the VM copy is

configured so that it is isolated from the original VM.

6.4 Leverage Dell EMC Unity to create gold images With Dell EMC All-Flash arrays, an administrator can create gold images to accelerate and simplify the

process of deploying new servers. Gold images can be used to deploy:

New host servers when using boot from SAN (except for Nano Server, which does not support boot

from SAN)

Guest VMs that use pass-through disks for boot disks

Guest VMs that boot from a virtual hard disk (although, in this case, using virtual hard disk with an OS

that has been sysprepped, as the gold image source, would be preferred)

Using gold images provides the following benefits:

Faster server provisioning with minimal reconfiguration.

Better SAN utilization. When a host or VM is provisioned from a gold image, only new data consumes

space on the storage array. Data that has not changed is read from the gold image source volume.

The steps to configure a Windows Server or Hyper-V gold image are as follows:

1. Create and map a Dell EMC Unity volume to a host server as a boot volume (LUN 0).

2. Build your base OS image, install roles and features, and fully configure and patch it. This will

minimize the changes that have to be made to each new server that is deployed using the gold

image.



3. Once the OS is fully staged, run Sysprep.exe and choose the Generalize, Out-of-box Experience,

and Shutdown options.

- After running Sysprep, if the server is a guest VM, use Hyper-V Manager to delete the guest VM.

This will delete the guest VM configuration files but will preserve the boot virtual hard disk. The

virtual hard disk is the only file needed for the gold image.

- Do not use SCVMM to delete the guest VM because it will also delete the virtual hard disk file.

Use Hyper-V Manager instead.

4. Once the server is powered down (which will ensure that it is in a consistent state), manually create a

Dell EMC Unity snapshot of the volume and set it to never expire. Assign it a descriptive name that

clearly identifies it as a gold source.

5. From the snapshot, create one or more thin clones and map them to new host servers.

6. Boot the new host servers and allow the initial boot process to complete.

7. Customize the server configuration as needed. Leverage PowerShell to automate configuration steps

that are repetitive.

Note: A snapshot that is designated a gold image source supports a maximum of 16 thin clones, and

therefore, a maximum of 16 new hosts can be provisioned from a single gold source. To deploy more servers,

create additional snapshots that can act as gold sources for more thin clones.



6.4.1 Gold images and preserving balanced Dell EMC Unity storage processors When a new volume is created on a Dell EMC Unity All-Flash array, it is owned by one storage processor

(SP) or the other (A or B). All future snapshots and thin clones of that volume will also be owned by the same

SP. If using gold images to deploy many new hosts, care should be taken to ensure that volume ownership

remains balanced between SPs A and B.

View or change the storage processor owner for a LUN

View the properties of a volume in Unisphere to view or change the current SP owner.

6.5 Using Dell EMC Unity for Hyper-V VM migration Microsoft provides native tools to move or migrate VMs with Windows Server 2012 and 2016 Hyper-V so

there are fewer use cases for using SAN-based snapshots to move VMs. When a guest VM is live migrated

from one node to another node within the same Hyper-V cluster configuration, no data needs to be copied or

moved because all nodes in that cluster have shared access to the underlying cluster shared volumes (CSV)

or SMB file shares.

However, when an administrator needs to migrate a guest VM from one host or cluster to another host or

cluster, the data (the virtual hard disks) must be copied to the target host or cluster, and this will consume

network bandwidth and may require significant time if the virtual hard disks are extremely large. This can also

consume additional storage space unnecessarily because another copy of the data is created.



When moving VMs to another host or cluster, it may be much quicker to leverage Dell EMC Unity to simply

unmap the host volume containing the VM configuration and virtual hard disks and map the volume to the

new target host or cluster. This can also be done using a using a thin clone.

While this might involve a small amount of down time for the VM being moved during a maintenance window,

it might be a much more practical approach than waiting for multiple terabytes of data to copy over the

network, consuming additional SAN space unnecessarily.

Boot from SAN for Hyper-V


7 Boot from SAN for Hyper-V Boot from SAN is supported by Windows Server hosts including Hyper-V, with the exception of Nano Server,

which requires a local boot disk configuration. In some cases, such as blade servers that do not have onboard

disks, booting from SAN may be the only option available. In most cases, physical hosts will support boot

from SAN given these requirements:

The host has a suitable, supported adapter that supports boot from SAN configuration (FC or iSCSI).

The FC fabric or iSCSI network is configured with zoning or a similar configuration to allow the

adapter in the host to see boot paths to a LUN through a host-to-LUN mapping on the Dell EMC Unity

array.

The host OS supports boot from SAN (Windows Server Hyper-V this case).

If multiple boot paths are presented to the host (recommended), the host OS must support MPIO.

This is accomplished by installing PowerPath or a supported DSM (native DSM in the case of

Windows Server) to support it.

Deciding whether to use on-board or SAN-based LUNs for boot is dependent on a number of design

considerations that are unique to each environment. There are advantages and disadvantages to both

options, and in some cases, using local disk may be preferred.

7.1 Boot from SAN advantages Advantages of using boot from SAN include:

Dell EMC Unity snapshots of boot volumes provide for quick host recovery.

Boot volumes can be replicated to another location for enhanced disaster recovery (DR) protection

when both sites use similar host server hardware.

Dell EMC Unity thin clones can be leveraged to create boot volumes from a gold-image snapshots for

quick server provisioning.

7.2 When to use boot from local disk It is recommended to boot from the local disk in the following scenarios:

When critical workloads or infrastructure roles such as AD, DNS, or DHCP need to remain online

during offline SAN maintenance or unplanned storage outages

When boot from SAN is not an option, such as when using SMB files shares to access shared

storage

7.3 Configure a Hyper-V host server to boot from SAN For guidance on configuring host servers to access FC or iSCSI LUNs, see the Configuring Hosts to Access

Fibre Channel (FC) or iSCSI Storage white paper.





In addition to the information in this guide, there are a few configuration steps and best practices to consider

when configuring boot from SAN:

If the host server has an onboard RAID controller and disks, either disable the controller or set the

boot order on the host server to use the FC HBA or iSCSI CNA as the first boot device. A boot path

must be presented to the host server before the adapter will be visible to the host, allowing it to be set

as a valid boot device in some cases. The configuration for a Dell PowerEdge™ R620 server is

shown in this example (shown by pressing F2 at boot to access the system setup).

Configure the FC or iSCSI adapter as the first boot device

When staging the host server, initially configure the LUN-to-host server mapping so the host can only

see a single boot path until the MPIO feature can be installed. This is not necessary when using a

thin clone of gold image because (typically) MPIO will already be configured as part of creating the

gold image when the OS was staged and prior to running Sysprep.

In Unisphere, verify that the boot LUN is mapped to the host as LUN ID = 0.

After installing the OS, install the MPIO feature, then add the additional boot paths. The host will see

multiple instances of the same LUN until PowerPath or the Microsoft DSM is installed.

Install MPIO feature



Install PowerPath or the native Microsoft DSM and reboot the server.

Make sure the boot settings for the FC HBA or iSCSI CNA have all the boot paths added. A QLogic

two-port QLE2562 FC HBA adapter is shown in this example with four boot paths for each HBA (eight

paths total). This is because each SP on the Dell EMC Unity system in this example is configured

with 4 FC ports.

QLogic FC HBA with multiple boot paths configured

Verify that the OS sees multiple boot paths to the boot disk and that there is only one instance of the

boot disk, as viewed from Disk Management in this example.

Boot from SAN disk with MPIO

Modify the MPIO registry settings per the guide listed previously in this section to ensure optimal

timeout settings.

Dell EMC Unity and NAS for Hyper-V


8 Dell EMC Unity and NAS for Hyper-V In addition to block storage, Dell EMC Unity All-Flash arrays support file-based storage through network

attached storage (NAS). Dell EMC Unity All-Flash arrays support SMB 3.1.1 which was released with

Windows 10 and Windows Server 2016. SMB 3.1.1 provides enhanced security and performance over

previous SMB versions.

With the release of Dell EMC Unity OE version 4.2, Dell EMC Unity All-Flash arrays use SMB2 for secure

channel communication by default. Previous versions of SMB are still supported with Dell EMC Unity with the

exception of SMB1 due to security and efficiency concerns. Microsoft has announced plans to depreciate

SMB1 due to these concerns.

Some key benefits offered with NAS on Dell EMC Unity All-Flash arrays includes failover and failback of NAS

servers and associated file shares between arrays, including Failover with Sync.

SMB shares can be presented to standalone Hyper-V hosts by using Universal Naming Convention (UNC)

paths or by using Microsoft SCVMM. SMB shares can be presented to Hyper-V clusters by using SCVMM

2012 or 2016.

For more information on NAS support with Dell EMC Unity, see the Dell EMC Unity: NAS Capabilities white

paper at Dell EMC Support (login required).

8.1 Configure Dell EMC Unity All-Flash array NAS server for Hyper-V The first step to configure SMB file access for Hyper-V is to configure one or more NAS servers on the Dell

EMC Unity All-Flash array:

1. Log in to Unisphere.

2. In the left pane, click Storage > File, and at the top of the center pane, click the NAS Servers tab.

Click + to launch the Create a NAS Server wizard.




3. Under General, provide a NAS server name, select a Tenant (optional), storage Pool, and Storage

Processor. Click Next. In this example, the NAS server is named U2_NAS01. As a best practice, if

creating multiple NAS servers, alternate the storage processor to balance the workloads on the SPs.

4. Under Interface, select the desired Ethernet Port on the SP for the NAS server to use. Assign an IP

Address to the NAS server, and provide the Subnet Mask. If required, provide a Gateway and

VLAN ID, and click Next.



5. Under Sharing Protocols, enable the option for Windows Shares (SMB, CIFS) and provide

standalone or AD configuration information. In this example, AD is used since all the Hyper-V servers

in the environment are domain members. The SMB Computer Name defaults to match the NAS

server name which is used in this example (change the SMB name if desired). Click Next.

6. Under DNS, add the DNS servers and click Next. DNS is required in this example because the NAS

server will be an AD member.



7. Under Replication, enable this option if desired and configure the replication mode, recovery point

objective (RPO), and replicate to (target) options. In this example, a replication target is not

configured (this can be configured later on). Click Next.

8. Under Summary, review the selections and click Finish.

9. Under Results, monitor the job until it completes, and click Close.

The new NAS server should now be listed in Unisphere. If desired, complete these optional steps:

10. Verify the presence of the new NAS server object on your AD domain.

11. Ping the IP address of the NAS server to verify it is available over the network.



8.2 Create a file system on the NAS server to host SMB shares for

Hyper-V Now that a NAS server is configured, the next step is to create a file system on the NAS server to host one or

more SMB shares for Hyper-V.

1. In Unisphere under Storage > File, at the top of the center pane, click the File Systems tab.

2. On the toolbar, click + to start the Create a File System wizard.

3. Under Protocol, from the drop-down list, select the desired NAS server. Verify that Windows Shares

(SMB) is set as the file system. In this example, the NAS server created previously is selected. Click

Next.

4. Under Name, provide a name for the file system and click Next.



5. Under Storage, from the drop-down list, select a disk pool and specify a size in GB or TB for the file

system. The file system is essentially a container that will host one or more SMB file shares. Thin

provisioning is enabled by default. Enable Compression if desired (as in this example), and click

Next.

6. Under Shares, enable SMB Share (Windows) and provide a name for the initial SMB share. Make a

note of the SMB share path and click Next.



7. Under SMB Share’s Other Settings, enable any additional properties. In the upper-right corner, click

Help to learn more about each property (none are selected in this example). Click Next.

8. Under Snapshot, click Enable Automatic Snapshot Creation if desired (recommended). Choose

an existing schedule or create a new one, and click Next.



9. Under Replication, configure replication settings. Replication is not configured in this example. Click

Next.

10. Under Summary, review the settings and click Finish.

11. Under Results, monitor the job until if completes, and click Close.

The file system will now be shown in Unisphere under the File Systems tab.



If desired, click the SMB Shares tab and create additional SMB shares on this file system. In this example,

the SMB share created in the previous screenshot is listed.

8.3 Access a Dell EMC Unity SMB share from a Hyper-V host server In this example, Hyper-V Manager is used to access a Dell EMC Unity NAS server SMB file share as the

storage location for a new VM.

1. Launch Hyper-V Manager from a Hyper-V host that is on the same network or VLAN as the Dell EMC

Unity NAS server that is hosting the SMB file share. The host is named S1330 in this example.

2. Right-click the host server and select New > Virtual Machine to start the New Virtual Machine

Wizard.



3. Under Specify Name and Location, provide a name for the VM, enable Store the virtual machine

in a different location, and enter the UNC path to the SMB file share. In this example, the path is

\\U2_NAS01\SMB_Share01 where U2_NAS01 is the name of the NAS server and SMB_Share01 is

the name of the SMB file share. Click Next.

4. Configure Generation, Memory, and Networking settings as desired.

5. Under Connect Virtual Hard Disk, the default setting is Create a virtual hard disk using the same

location as specified in step 3, which in this case is the SMB file share.

6. Configure the desired Installation Options, click Next, and click Finish.



8.3.1 Path defaults and permissions best practices If an SMB file share will be the default location for new VMs, then as a best practice and as a time-saving tip,

edit the Hyper-V server properties and set the default paths to locations on the SMB file share.

1. Access Hyper-V Manager.

2. Right-click the host name and select Hyper-V settings.

3. Set the default paths for Virtual Hard Disks and Virtual Machines to locations on the SMB file

share, as shown in this example.

When creating an SMB file share in Unisphere, by default, the Everyone group is granted full share and

security permissions. It is a best practice to restrict these permissions.

Note: If leveraging SCVMM to present SMB file shares to a Hyper-V host or cluster, SCVMM will modify the

permissions automatically.

4. Launch Computer Management from a host server on the same network or VLAN to connect to the

Dell EMC Unity NAS server where the SMB file share is located. The path is \\U2_NAS01 in this

example. Optionally, Active Directory Users and Computers can be used.



5. Once connected to the NAS server, expand to Shared Folders > Shares. Right-click the SMB file

share name and select Properties. The SMB share is named SMB_Share01 in this example.

6. Modify the permissions under the Share Permissions and Security tabs as desired for your

environment, such as limiting access to specific users, user groups, and computer hosts. For

additional guidance on modifying share and security permissions, see Microsoft TechNet.

8.4 Present Dell EMC Unity SMB file shares to Hyper-V clusters SMB file shares can be presented as shared storage to Hyper-V cluster nodes by leveraging Dell EMC Unity

SMI-S integration with Microsoft SCVMM. SCVMM does not present SMB file shares to a Hyper-V cluster as

CSVs like it does with block storage. However, the functionality of an SMB file share presented to a Hyper-V

cluster is essentially the same as a CSV.

For those accustomed to leveraging block storage presented as CSVs, there are some differences that are

important to understand. For example, SMB file shares presented to a cluster are not visible under the

storage in Failover Cluster Manager. Also, an extra step that is required with block storage to add a volume

as a CSV before it can be used for VMs is avoided, making for a simpler configuration. SMB file shares

presented to a Hyper-V cluster are managed transparently in the background by SCVMM.

As for the functional differences between a CSV and an SMB file share, leveraging SMB file shares for shared

storage on Hyper-V clusters requires an investment in SCVMM, whereas block storage does not. However,

SCVMM will manage either kind of storage: block or SMB. SCVMM provides full integration with Dell EMC

Unity All-Flash arrays. For more information on SMI-S integration, see the Dell EMC Unity Family SMI-S

Programmer’s Guide.

The steps in section 8.4.1 assume that an SCVMM 2012 or 2016 server is already configured in the

environment per Microsoft best practices.






8.4.1 Configure SCVMM with SMI-S to use SMB file shares

1. Log in to the SCVMM administrator console.

2. In the Fabric workspace, click Storage. On the Home tab, under the ribbon bar click Add

Resources and from the drop-down list select Storage Devices to launch the Add Storage Device

Wizard.

3. Under Select Provider Type, select SAN and NAS devices discovered and managed by a SMI-S

provider and click Next.



4. Under Specify Discovery Scope, provide the management IP address of the Dell EMC Unity system

with the NAS server, file system, and SMB share. In this example, the IP address is 100.88.135.102.

Also provide an SCVMM Run As account that has administrator rights on the domain. In this

example, the Run As account is named intuitively as Unity SMI-S run-as Account. Click Next.

5. Allow the wizard to discover and import the storage device information. This may require several

minutes. If prompted to import a certificate (if using SSL - recommended), click Import to continue.



6. Complete the steps in the Add Storage Device Wizard. Verify that the SMB file shares are listed

under File Servers in SCVMM. There are two NAS servers, each with one SMB share, in this

example.

7. In SCVMM in the VMs and Services workspace, expand All Hosts, right-click the server cluster, and

select Properties.

8. Under File Share Storage, click Add, and from the drop-down list select the file share (listed by UNC

path).



9. Once the SMB file share has been assigned, verify the Access Status column shows as green. In

this example, both available SMB file shares are assigned to the Hyper-V cluster.

VMs can now be deployed to either Dell EMC Unity SMB file share in this example because they are now

cluster-aware resources managed by SCVMM through SMI-S.

Technical support and additional resources


A Technical support and additional resources

Dell EMC Support provides hardware and software support for the Dell EMC Unity platform.

For additional Dell EMC Unity information, documentation, or release notes, visit the Dell EMC Unity

Technical Documentation and Info Hub pages

The Dell EMC Data Center Transformation site is focused on enabling customers to gain understanding

regarding the transformation of their IT infrastructure utilizing new technologies.

Dell TechCenter is an online technical community where IT professionals have access to numerous resources

for Dell EMC software, hardware, and services.

A.1 Related resources

The following referenced or recommended Dell EMC publications and resources are located at Dell EMC

Support unless indicated by a different hyperlink:

Dell EMC Unity: Introduction to the Platform

Dell EMC Unity: OE Version 4.2 Technical Primer

Dell EMC Unity: Unisphere Overview

Dell EMC Unity Best Practices Guide for Performance and Availability

Dell EMC Unity: NAS Capabilities

Configuring Hosts to Access SMB File Systems on Dell EMC Unity

Dell EMC Unity Family - Configuring Hosts to Access Fibre Channel (FC) or iSCSI Storage

Dell EMC Unity Family SMI-S Programmer’s Guide

Dell EMC Unisphere Management RESTful API guides (<management_ip> is the management IP

address for your Dell EMC Unity system):

- Programmers Guide: https://<management_ip>/apidocs/programmers-guide/index.html

- Reference Guide: https://<managment_ip>/apidocs/index.html

Dell EMC Unity Family Unisphere Command Line Interface User Guide

Dell EMC Unity Simple Support Matrix (for software and hardware)

Dell EMC Unity: Snapshots and Thin Clones

Dell EMC Unity: Dynamic Pools

Dell EMC Unity: Performance Metrics

Dell EMC Unity: Replication Technologies

Dell EMC Unity: Compression

Dell EMC Unity: Data at Rest Encryption

AppSync User and Administration Guide

AppSync Performance and Scalability Guidelines

PowerPath Installation and Administration Guide for Microsoft Windows

http://support.emc.com/

https://www.emc.com/en-us/documentation/unity-family.htm

http://bit.ly/unityinfohub_master

https://www.emc.com/en-us/data-center-transformation/index.htm

http://en.community.dell.com/techcenter/








https://elabnavigator.emc.com/vault/pdf/EMC_Unity_ESSM.pdf?key=1496639784237

Technical support and additional resources


Also see the following third-party referenced or recommended publications and articles:

QLogic Execution Throttle and Windows Queue Depth Explained

Microsoft TechNet Library

Microsoft PowerShell Developer Network (MSDN)

http://support.qlogic.com/SupportCenter/articles/Question_Answers/2718


https://msdn.microsoft.com/powershell

Dell EMC Unity Storage with Microsoft Hyper-V · PDF file2 Dell EMC Unity Storage with...

Documents

Transcript of Dell EMC Unity Storage with Microsoft Hyper-V · PDF file2 Dell EMC Unity Storage with...