This article was originally published in NetApp’s Tech OnTap Newsletter.
To receive the newsletter monthly and enjoy other great benefits, sign up
today at www.netapp.com/us/communities/tech-ontap
Top Five Hyper-V Best Practices
By Chaffie McKenna
Chaffie McKenna
Reference Architect
NetApp
Chaffie joined NetApp in early 2008
as part of NetApp’s Microsoft®
Alliance Engineering team based in
Seattle, WA. She focuses heavily on
virtualization, especially Microsoft
Hyper-V™ and SCVMM. Her
experience with virtualization goes
back 10 years, when virtualization
was in its infancy.
Read the Latest on
Hyper-V and NetApp
Chaffie McKenna blogs regularly about
all things Hyper-V and other topics
related to Microsoft environments
on her Microsoft Environments blog
(http://blogs.netapp.com/msenviro/).
Recent posts include:
• Is Hyper-V data center ready?
• Networking best practices
• Provisioning best practices
Microsoft Hyper-V virtualization technology
has been shipping for more than a year.
Tech OnTap profiled the use of Hyper-V
with NetApp® technology in several past
articles, including an overview article
(www.netapp.com/us/communities/tech-
ontap/hyperv.html) and a detailed case
study of one customer’s experiences
(www.netapp.com/us/communities/tech-
ontap/avanade-hyperv.html).
NetApp has been involved with hundreds of
Hyper-V deployments and has developed a
detailed body of best practices for Hyper-V
deployments on NetApp. Tech OnTap asked
me to highlight the top five best practices
for Hyper-V on NetApp, with special
attention to the recently released Hyper-V
Server 2008 R2.
• Network configuration
• Setting the correct iGroup and LUN
protocol type
• Virtual machine disk alignment
• Using cluster shared volumes (CSVs)
• Getting the most from NetApp storage
software and tools
You can find full details on these items
and much more in NetApp Storage Best
Practices for Microsoft Virtualization which
has been updated to include Hyper-V R2
(www.netapp.com/us/library/technical-
reports/tr-3702.html).
BP #1: Network Configuration
in Hyper-V Environments
There are two important best practices
to mention when it comes to network
configuration:
• Be sure to provide the right number of
physical network adapters on Hyper-V
servers.
• Take advantage of the new network
features that Hyper-V R2 supports if
at all possible.
Physical network adapters
Failure to configure enough network
connections can make it appear as though
you have a storage problem, particularly
when using iSCSI. Smaller environments
require a minimum of two or three network
adapters, while larger environments require
at least four or five. You may require far
more. Here’s why:
• Management. Microsoft recommends a
dedicated network adapter for Hyper-V
server management.
• Virtual machines. Virtual network
configurations of the external type require
a minimum of one network adapter.
• IP storage. Microsoft recommends that IP
storage communication have a dedicated
network, so one adapter is required and
two or more are necessary to support
multipathing.
Table 1) Standalone Hyper-V servers.
Complete Hyper-V
Mgmt. VMs iSCSI Cluster Migration CSV Total Best Practices
Non-prod. DAS 1 1 n/a n/a n/a n/a 2 If you’re deploying Hyper-V with
NetApp storage, access to the
FC 1 1 n/a n/a n/a n/a 2 latest best practices information is
iSCSI 1 1 1 n/a n/a n/a 3 indispensible.

Production DAS 1 1 or 2 n/a n/a n/a n/a 2 or 3 Download the latest detailed guides:

FC 1 1 or 2 n/a n/a n/a n/a 2 or 3 • NetApp Storage Best Practices for

Microsoft Virtualization (www.netapp.
iSCSI 1 1 or 2 2 n/a n/a n/a 4 or 5 com/us/library/technical-reports/
tr-3702.html)
• NetApp Implementation Guide for
Microsoft Virtualization (www.netapp.
Table 2) Clustered Hyper-V servers. com/us/library/technical-reports/
tr-3733.html).
Mgmt. VMs iSCSI Cluster Migration CSV Total
Non-prod. FC 1 1 n/a 1 n/a n/a 3

iSCSI 1 1 1 1 n/a n/a 4

Production FC 1 1 or 2 n/a 1 n/a n/a 3 or 4

iSCSI 1 1 or 2 2 1 n/a n/a 5 or 6

• Windows® failover cluster. Windows
failover cluster requires a private network.
• Live migration. This new Hyper-V
R2 feature supports the migration
of running virtual machines between
Hyper-V servers. Microsoft recommends
configuring a dedicated physical network
adapter for live migration traffic.
• Cluster shared volumes. Microsoft
recommends a dedicated network to
support the communications traffic
created by this new Hyper-V R2 feature.
Tables 1 through 4 above and on the next
page will help you choose the right number
of physical adapters.
New network features
Windows Server® 2008 R2 supports a
number of new networking features. NetApp
recommends configuring these features on
your Hyper-V servers and taking advantage
of them whenever possible. Be aware that
some or all of them may not be supported
by your server and network hardware.
(See box on page 5 for details.)
BP #2: Selecting the Correct
iGroup and LUN Protocol Type
When provisioning a NetApp LUN for use
with Hyper-V, you must specify specific
initiator groups (iGroups) and the correct
LUN type. Incorrect settings can make
deployment difficult and performance
can suffer.
Initiator groups
FCP and iSCSI storage must be masked
so that the appropriate Hyper-V server
and virtual machines (VMs) can connect to
them. With NetApp storage, LUN masking is
handled by iGroups.
• When dealing with individual Hyper-V
servers or VMs, you should create an
iGroup for each system and for each
protocol (FC and iSCSI) that system uses
to connect to the NetApp storage system.
• When dealing with a cluster of Hyper-V
servers or VMs, you should create an
individual iGroup for each protocol that
the cluster of systems uses to connect to
the NetApp storage system.
It’s easier to manage iGroups by using
NetApp SnapDrive®. SnapDrive cuts
down on the confusion because it knows
which OS you are using and automatically
configures that setting for your iGroups.
LUN types
The LUN Protocol Type setting determines
the on-disk layout of the LUN. It is important
to specify the correct LUN type to make sure
that the LUN aligns properly with the file
system it contains. (See the following tip for
an explanation.) This issue is not unique to
NetApp storage. Any storage vendor or host
platform may exhibit this problem.
Tip: The LUN type you specify depends
on your OS, OS version, disk type, and
Data ONTAP® version. For complete
information on LUN types for different
operating systems, refer to the Block
Access Management Guide for your
version of Data ONTAP.
Tables 5 and 6 on page 4 will help you
choose the correct LUN type.
BP #3: Virtual Machine
Disk Alignment
Tip: This tip is closely tied to the previous
one, since failure to follow the previous tip
will result in misalignment. The problem
of virtual machine disk alignment is not
unique to Hyper-V, nor is it unique to NetApp
storage. This problem exists in any virtual
environment on any storage platform.
Table 3) Clustered Hyper-V servers using live migration.

Mgmt. VMs iSCSI Cluster Migration CSV Total

Non-prod. FC 1 1 n/a 1 1 n/a 4

iSCSI 1 1 1 1 1 n/a 5

Production FC 1 1 or 2 n/a 1 1 n/a 4 or 5

iSCSI 1 1 or 2 2 1 1 n/a 6 or 7

Table 4) Clustered Hyper-V servers using live migration and CSV.

Mgmt. VMs iSCSI Cluster Migration CSV Total

Non-prod. FC 1 1 n/a 1 1 1 5

iSCSI 1 1 1 1 1 1 6

Production FC 1 1 or 2 n/a 1 1 1 5 or 6

iSCSI 1 1 or 2 2 1 1 1 7 or 8

MBR + Unused Space

Host/Guest
Block 0 Block 1 Block 2 Block 3
File System

LUN

Figure 1) Virtual disk misalignment.

This problem occurs because, by default,
many guest operating systems, including
Windows 2000 and 2003 and various Linux®
distributions, start the first primary partition
at sector (logical block) 63. This behavior
leads to misaligned file systems because the
partition does not begin at a block boundary.
As a result, every time the virtual machine
wants to read a block, two blocks have to be
read from the underlying LUN, doubling the
I/O burden (see Figure 1 above).
The situation becomes even more
complicated when virtual machines are
managed as files within the Hyper-V server’s
file system, because it introduces another
layer that must be properly aligned. This is
why selecting the LUN type is so critical.
• NetApp strongly recommends correcting
the offset for all VM templates, as well
as any existing VMs that are misaligned
and are experiencing an I/O performance
issue. (Misaligned VMs with low I/O
requirements may not benefit from the
effort to correct the misalignment.)
• When using virtual hard disks (VHDs),
NetApp recommends using fixed-size
VHDs in your Microsoft Hyper-V virtual
environment wherever possible, especially
in production environments, because
proper file system alignment can be reliably
achieved only on fixed-size VHDs. Avoid
the use of dynamically expanding and
differencing VHDs where possible, because
file system alignment can never be reliably
achieved with these VHD types.
The best practices guide provides complete
procedures for identifying and correcting
alignment problems (www.netapp.com/us/
library/technical-reports/tr-3702.html).
BP #4: Using Cluster
Shared Volumes
Cluster shared volumes are a completely
new feature in Hyper-V R2. If you’re familiar
with VMware®, you can think of a CSV as
being somewhat akin to VMFS (although
there are significant differences).
A CSV is a “disk” that is connected to the
Hyper-V parent partition and shared between
multiple Hyper-V server nodes configured
as part of a Windows failover cluster. A CSV
can be created only from shared storage,
such as a LUN provisioned on a NetApp
storage system. All Hyper-V server nodes in
the failover cluster must be connected to the
shared storage system.
CSVs have many advantages, including:
• Shared namespace. CSVs do not need
to be assigned a drive letter, reducing
restrictions and eliminating the need to
manage GUIDs and mount points.
• Simplified storage management.
More VMs share fewer LUNs.
• Storage efficiency. Pooling VMs on the
same LUN simplifies capacity planning
and reduces the amount of space
reserved for future growth, because it is
no longer set aside on a per-VM basis.
CSV Dynamic I/O Redirection allows storage
and network I/O to be redirected within
a failover cluster if a primary pathway is
interrupted. The following recommendations
apply specifically to the use of CSVs and
are intended to minimize the impact of I/O
redirection:
• In addition to the NICs installed in the
Hyper-V server for management, VMs, IP
storage, and more (see Best Practice #1),
NetApp recommends that you dedicate
a physical network adapter to CSV traffic
only. The physical network adapter should
be a gigabit Ethernet (GbE) adapter at a
minimum. If you are running large servers
(16 LCPUs+, 64GB+), planning to use
CSVs extensively, planning to dynamically
balance VMs across the cluster by using
SCVMM, and/or planning to use live
migration extensively; you should consider
10 Gigabit Ethernet for CSV traffic.
• NetApp strongly recommends that you
configure MPIO on all Hyper-V cluster
nodes, to minimize the opportunity
Table 5) LUN types for use with Data ONTAP 7.3.1 and later.

Data ONTAP 7.3.1 Windows Server 2008 Windows Server 2008 Windows Server 2008
or Later Physical Server Hyper-V Server Hyper-V Server
without Hyper-V Physical Disk Pass-through Disk
With SnapDrive Installed windows_gpt hyper_v LUN type of child OS

Without SnapDrive Installed windows_2008 windows_2008 LUN type of child OS

Table 6) LUN types for use with Data ONTAP 7.2.5 through 7.3.0.

Data ONTAP 7.2.5 Windows Server 2008 Windows Server 2008 Windows Server 2008
through 7.3.0 Physical Server Hyper-V Server Hyper-V Server
without Hyper-V Physical Disk Pass-through Disk
With SnapDrive Installed windows_gpt windows_gpt LUN type of child OS

Without SnapDrive Installed windows_2008 windows_2008 LUN type of child OS

for CSV I/O redirection to occur. CSV
I/O Redirection is not a substitute for
multipathing or for proper planning of
storage layout and networking, which
will minimize single points of failure in
production environments.
• Once you recognize that I/O redirection is
occurring on a CSV, you may want to live
migrate all affected VMs on the affected
cluster node to another Hyper-V cluster
node to restore optimal performance until
any I/O pathway problems are diagnosed
and repaired.
The best practices guide describes
additional best practices that pertain
specifically to backup and VM provisioning
with CSVs.
BP #5: NetApp Storage
Software and Tools
NetApp provides a variety of storage
software and tools that can simplify
operations in a Hyper-V environment.
With the release of Hyper-V R2, minimum
requirements have changed for many
software elements:
• As a minimum, NetApp recommends
using Data ONTAP 7.3 or later with
Hyper-V virtual environments.
• The Windows Host Utilities Kit modifies
system settings so that the Hyper-V parent
or child OS operates with the highest
reliability possible when connected to
NetApp storage. NetApp strongly recom-
mends that the Windows Host Utilities
Kit be installed on all Hyper-V servers.
Windows Server 2008 requires Windows
Host Utilities Kit 5.1 or later. Windows
Server 2008 R2 (Hyper-V R2) requires
Windows Host Utilities Kit 5.2 or later.
• Highly available storage configurations
require the appropriate version of the
Data ONTAP DSM for Windows MPIO.
Windows Server 2008 requires Data
ONTAP DSM 3.2R1 or later. Windows
Server 2008 R2 requires Data ONTAP
DSM 3.3.1 or later. You should set the
least queue depth policy when using
MPIO. (This is the default setting.)
• NetApp recommends NetApp SnapDrive
on all Hyper-V and SCVMM servers
to enable maximum functionality and
support of key features. For Microsoft
Windows Server 2008 installations where
the Hyper-V role is enabled and for
Microsoft Hyper-V Server 2008, install
NetApp SnapDrive for Windows 6.0 or
later. For Microsoft Windows Server 2008
R2 installations where the Hyper-V role is
enabled and for Microsoft Hyper-V Server
2008 R2 to support:
-- Existing features (no new R2 features),
install NetApp SnapDrive for Windows
6.1P2 or later.
-- New features (all new R2 features),
install NetApp SnapDrive for Windows
6.2 or later.
• NetApp SnapDrive for Windows 6.0 or
later can also be installed in supported
child operating systems that include
Microsoft Windows Server 2003,
Microsoft Windows Server 2008, and
Microsoft Windows Server 2008 R2.
For the latest information on supported
software versions, refer to the NetApp
Interoperability Matrix (http://now.netapp.
com/matrix/mtx/login.do). You must have
a NOW™ (NetApp on the Web) account to
access this resource.
Conclusion
If you pay attention to the best practices
I’ve outlined here, you can avoid most of
the pitfalls of configuring your Hyper-V
environment. For complete details on these
procedures and much more, refer to the
Hyper-V best practices guide (www.netapp.
com/us/library/technical-reports/tr-3702.
html) and Hyper-V implementation guide
(www.netapp.com/us/library/technical-
reports/tr-3733.html).
 New Windows Server 2008 R2 Networking Features
Windows Server 2008 R2 adds important new capabilities that you should use in your
Hyper-V environment if your servers and network hardware support them:

Large Send Offload (LSO) and Checksum Offload (CSO)

LSO and CSO are supported by the virtual networks in Hyper-V. In addition, if your
physical network adapters support these capabilities, the virtual traffic is offloaded to
the physical network as necessary. Most network adapters support LSO and CSO.

Jumbo frames
With Windows 2008 R2, jumbo frame enhancements converge to support up to 6
times the payload per packet. This makes a huge difference in overall throughput and
reduces CPU utilization for large file transfers. Jumbo frames are supported on physical
networks and virtual networks, including switches and adapters. For physical networks,
all intervening network hardware (switches and so on) must have jumbo frame support
enabled as well.

TCP chimney
This allows virtual NICs in child partitions to offload TCP connections to physical
adapters that support it, reducing CPU utilization and other overhead.

Virtual machine queue

VMQ improves network throughput by distributing network traffic for multiple VMs
across multiple processors, while reducing processor utilization by offloading packet
classification to the hardware and avoiding both network data copy and route lookup
on transmit paths. VMQ is compatible with most other task offloads, and therefore it
can coexist with large send offload and jumbo frames. However, where TCP chimney
is supported by the NIC, VMQ takes precedence.

Tech OnTap
SUBSCRIBE NOW
Tech OnTap provides monthly IT insights
plus exclusive access to real-world best
practices, tips and tools, behind the
scenes engineering interviews, demos,
peer reviews, and much, much more.

Visit www.netapp.com/us/communities/
tech-ontap to subscribe today.

NetApp creates innovative storage and

data management solutions that accelerate
business breakthroughs and deliver
outstanding cost efficiency. Discover our
passion for helping companies around the
www.netapp.com world go further, faster at www.netapp.com.
© 2009 NetApp. All rights reserved. Specifications are subject to
change without notice. NetApp, the NetApp logo, Go further, faster,
Data ONTAP, NOW, and SnapDrive are trademarks or registered
trademarks of NetApp in the U.S. and other countries. Linux is a
registered trademark of Linus Torvalds. Microsoft, Hyper-V, Windows,
and Windows Server are trademarks or registered trademarks of
Microsoft Corporation. VMware is a registered trademark of VMware,
Inc. All other brands or products are trademarks or registered
trademarks of their respective holders and should be treated as such.