microsoft hyper v with ibm san volume controller and ibm...

© Copyright IBM Corporation, 2014

Microsoft Hyper-V with IBM SAN Volume Controller and IBM Storwize family

products

Best practices and guidelines

IBM Systems and Technology Group ISV Enablement

March 2014

https://twitter.com/

Microsoft Hyper-V with IBM SAN Volume Controller and Storwize family products

Table of contents

Abstract ..................................................................................................................................... 1

Introduction .............................................................................................................................. 1

IBM systems ............................................................................................................................. 1

Storwize family products and SVC...................................................................................................... 1

System x servers ............................................................................................................................... 3

Hyper-V overview ..................................................................................................................... 3

Prerequisites ............................................................................................................................. 4

Storage configuration .............................................................................................................. 5

Volumes............................................................................................................................................. 5

Thin provisioning ................................................................................................................................ 8

Multipathing ....................................................................................................................................... 9

SAN zoning .......................................................................................................................................10

Virtual machine storage ......................................................................................................... 11

Fibre Channel ...................................................................................................................................11

Hyper-V virtual Fibre Channel configuration .................................................................12

iSCSI ................................................................................................................................................16

FCoE ................................................................................................................................................18

VHD volumes ....................................................................................................................................18

SAS ..................................................................................................................................................19

Direct attached ..................................................................................................................................19

Pass-through disks............................................................................................................................20

Hyper-V CSV Cache .........................................................................................................................20

Hyper-V clustering .................................................................................................................. 20

Guest clusters ...................................................................................................................................21

Virtual machine migrations .................................................................................................... 21

Hyper-V storage live migration ..........................................................................................................22

Storwize seamless data migration .....................................................................................................22

Resource metering ................................................................................................................. 23

System Center 2012 VMM ...................................................................................................... 23

Backup .................................................................................................................................... 25

IBM FlashCopy .................................................................................................................................26

Tivoli Storage FlashCopy Manager ....................................................................................................26

Easy Tier ................................................................................................................................. 28

IBM Real-time Compression .................................................................................................. 28

Conclusion .............................................................................................................................. 30

Resources ............................................................................................................................... 31

Trademarks and special notices ........................................................................................... 32


1

Abstract

This paper covers IBM Storwize family products and IBM System Storage SAN Volume Controller (SVC) best practices for Microsoft Hyper-V. The focus includes storage-specific configuration guidance including array configuration, connectivity and disk options, backup, and integration with Microsoft System Center 2012 Virtual Machine Manager (VMM).

Introduction

Virtualization and private cloud environments are now in wide spread use in most data centers. Both

server and storage virtualization have improved efficiency and lowered IT costs while providing highly

scalable infrastructures and a much smaller footprint. Microsoft® Hyper-V allows IT organizations to

consolidate resources and still use the familiar Microsoft interfaces and technology for their virtualized

solutions.

The IBM® Storwize® family products and IBM System Storage® SAN Volume Controller provide robust

and reliable feature-rich storage for Hyper-V. All of these storage systems run the same code base,

architecture and feature sets, and are compliant with Hyper-V and Storage Management Initiative

Specification (SMI-S) standards that Microsoft System Center 2012 Virtual Machine Manager (VMM) relies

on. The result is a highly efficient, integrated, and easily managed virtual environment that combines the

benefits of both virtual storage and servers.

The content in this paper is a collection of best practices and guidance for Hyper-V implementation with a

focus on storage-specific topics. It is not intended to be a detailed step-by-step guide to install and

configure Hyper-V, (there are abundant resources available to help with that). This paper is about the

general guidelines for Hyper-V with IBM Storwize family and SVC systems; however, not everything

applies to all customer situations. Each feature or suggestion must be carefully reviewed and evaluated to

determine if it makes sense for a given environment.

IBM systems

This section describes the features of the IBM Storwize family products and IBM System x® servers. IBM

storage and servers are tightly integrated and provide proven combinations for robust, reliable, and

scalable solutions.

Storwize family products and SVC

The IBM Storwize family products and SVC include the following storage systems.

IBM Storwize V7000

IBM Storwize V7000 Unified – combined block and file storage

IBM Storwize V5000

IBM Storwize V3500 (China)

IBM Storwize V3700

IBM Flex System® V7000 Storage Node

IBM SAN Volume Controller models


2

This paper refers to software and features that are common across all Storwize family products and SVC

systems, unless otherwise noted. The system used for proof of concept testing was IBM Storwize V7000.

The IBM Storwize family products and SVC systems provide internal storage and also external storage

virtualization, with the exception of Storwize V3700 which is internal only; making it possible to integrate

with and manage existing heterogeneous storage along with the internal storage from a single interface.

The web-based management GUI runs directly on the IBM Storwize family products and SVC systems and

can be accessed by a web browser.

Figure 1: IBM Storwize V7000

Each IBM Storwize family product consists of a control enclosure and optionally multiple expansion

enclosures. This provides 3.5 inch or 2.5 inch serial-attached SCSI (SAS) drives for the internal storage.

The SVC system does not support expansion enclosures or internal disk storage, but virtualizes external

disk storage only. The systems now include support for clustering multiple Storwize family products of the

same model together, allowing for additional scalability.

Figure 2: View of the Storwize family and SVC management GUI

The IBM Storwize family products and SVC also include a function called IBM System Storage

Easy Tier®. This takes advantage of the high performance solid-state drives (SSDs) by automatically


3

moving the most active data from the hard disk drives (HDDs) to the SSDs using a very sophisticated

algorithm.

In addition, there is also a full array of features including:

8 Gbps Fibre Channel (FC), 1 Gbps iSCSI, or optionally 10 GbE iSCSI

Seamless data migration to internal or external arrays

Thin provisioning, volume mirroring, and thin mirroring

Global Mirror and Metro Mirror replication, IBM FlashCopy® with 256 targets,

cascaded, incremental, space efficient (thin provisioned)

Integration with IBM Tivoli® Productivity Center

You can find more detailed information about IBM Storwize family products and SVC systems at:

ibm.com/systems/storage/disk

System x servers

IBM System x servers can deliver the performance and reliability required for virtualizing mission-critical

applications on Hyper-V with Microsoft Failover Clustering. A full line of rack mount and blade systems are

available to fit any budget or data center requirements. System x servers are available in several

performance ranges, from mission-critical or general business level, to entry-level systems that allow a

company to start small and expand as needed.

You can find details about the full line of System x servers and more information at:

ibm.com/systems/x/index.html

Hyper-V overview

Hyper-V is Microsoft’s hypervisor included with recent versions of Microsoft Windows® Server, and it

continues to gain ground in the competitive server virtualization market. It offers Microsoft-based

infrastructure environments a built-in, lower-cost server virtualization solution, along with add-on

integration and management products such as System Center 2012 VMM to simplify administering a

growing virtual data center.

Hyper-V supports many storage-specific features and enhancements, including:

Virtual Fibre Channel SAN switches and adapters

iSCSI connectivity

Pass-through disks

Storage migration

Storage automation with Microsoft System Center 2012 Virtual Machine Manager

Virtual hard disk (VHD) and the improved virtual hard disk X (VHDX) format

Cluster Shared Volumes (CSV) cache

Virtual machine (VM) snapshots

Resource metering


4

Hyper-V with Windows Server 2012 R2 includes additional new features and improvements. At the time of

this writing, Windows 2012 R2 is not fully supported on IBM servers and all software components,

therefore the R2 features are not included in this version of the paper.

Throughout this paper, the Hyper-V host server is referred to as the parent partition. This is where the

Hyper-V hypervisor is installed as a Windows feature. The virtual machines are referred to as guests or

child partitions.

You can find in depth information about Hyper-V architecture and features on the Microsoft website at:

http://technet.microsoft.com/en-us/library/hh831531.aspx

Prerequisites

The remaining sections of this paper cover best practices for Hyper-V environments with IBM Storwize

family and SVC systems. The paper assumes systems administrator level knowledge of Windows servers,

Hyper-V, storage, SAN, and networking as some of the information is presented at a higher level. Newer

concepts will include more details or links to in-depth information.

Before configuring any environment, it is important that all systems and components have the latest

supported firmware and drivers installed. Unusual technical issues are often resolved by applying these

overlooked updates. Additionally, Microsoft security and important patches must be applied and up to

date. There are also specific Microsoft patches that might be needed to provide functionality or stability in

a Hyper-V environment. You can find a list of these at:

http://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-

2012.aspx

Note: Install the IBM Subsystem Device Driver Device Specific Module (SDDDSM) multipath software

before applying Microsoft patches. Refer to the note in the “Multipathing” section of this paper for more

details on the reason and KB number of the conflicting patch.

A list of recommended patches for failover cluster environments is available at:

http://support.microsoft.com/kb/2784261

Windows PowerShell can also be used to automatically check for any missing patches or fixes related to

Hyper-V and failover clustering environments. You can find a PowerShell script for Windows Server 2012

from Microsoft at:

http://blogs.technet.com/b/cedward/archive/2013/05/24/validating-hyper-v-2012-and-failover-clustering-

2012-hotfixes-and-updates-with-powershell.aspx

It is also important to verify that a newer OS or application is supported with the planned hardware or

feature sets, whether it be servers, storage, applications or network devices. For example, Windows

Server 2012 has been tested in depth, with wide support statements, while Windows 2012 R2 might not be

fully supported yet due to its relatively recent release date. Because the support levels are always

updated, checking the IBM support links provided in this paper is the best way to ensure a given system

and software combination is compatible.

The IBM support site offers a useful utility for verifying supported combinations of hardware, software,

protocols, and operating systems. It is called the System Storage Interoperation Center (SSIC) and it


5

provides detailed information on supported combinations on IBM systems. When in doubt, this is the best

source to verify interoperability. You can find the tool at:

ibm.com/systems/support/storage/ssic/interoperability.wss

When setting up the Hyper-V host server, Microsoft recommends keeping the number of roles and

features limited to Hyper-V, failover clustering, and Multipath I/O. Running additional components can

introduce instability and complicate troubleshooting. The reasoning behind this is because when the

Hyper-V role is installed, the host OS becomes the parent partition and the hypervisor is added between

the parent partition and the hardware. Microsoft recommends the Hyper-V host server be primarily

dedicated to running as a hypervisor, to minimize the additional load and complexity of other services

running on it.

When configuring the default path for virtual hard disks, the best practice is to locate it on a non-system

drive. This is to avoid system disk latency and prevent the possibility of the server running out of disk

space.

Antivirus software running on a Hyper-V environment needs to have the recommend Hyper-V files

excluded from scanning to avoid instability and unexpected issues. You can find the list of file exclusions

and more detailed information about this topic at:

http://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-

hosts.aspx

This is far from a complete list of prerequisites for Hyper-V environment; however, covering these areas

can help avoid some of the more common issues that can create unexpected instability. For a complete

list of prerequisites and detailed best practices for each aspect of Hyper-V, search the Microsoft TechNet

website. You can find an excellent Hyper-V predeployment and configuration guide from Microsoft at:

http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-

easy-checklist-form.aspx

Storage configuration

A successful Hyper-V implementation takes some planning to avoid performance or capacity issues as the

environment grows. The storage configuration deployed depends on how the volumes will be connected

and the type of workloads running on them.

To have the best performance and reliability, all of the storage components need to be configured

optimally and working together, including the SAN, volume structures, host I/O management and sizing.

Volumes

Volumes can be thin provisioned or standard, with most environments opting for thin provisioned volumes

as the most efficient configuration. More information on this is covered later in the “Thin provisioning”

section.

It is common for Hyper-V hosts to have very large volumes to store multiple virtual hard disks. In such

configurations, for performance reasons, it is important to ensure there are adequate disks in the

underlying storage pools to support the expected I/O load, as well as the needed space. However, even if


6

such performance ceilings are reached, Hyper-V and Storwize family systems provide options such as

virtual machine and storage migration to quickly remedy the situation.

Virtual machines can use one of the several directly connected volume methods. These types of volumes

offer the best performance and overall control. When using directly connected volumes, they are sized

closer to what typical physical server environments use. Another important use for directly attached

volumes is when using backup solutions that use Microsoft Volume Shadow Copy Service (VSS) to take

snapshots and restore individual volumes, an approach that cannot be used with shared virtual hard disk

(VHD) volumes.

In most instances, VHD files are recommended and provide adequate balanced performance. However,

directly connected drives might be required by an application or are needed for the highest performance.

Often, a virtual server uses a combination of direct-attached and VHD files to balance efficiency and

performance. If performance problems persist with VHDs, try placing heavy I/O data on directly attached.

Volume capacity needs to consider enough space for dynamically expanding VHD files, which start out at

a minimal size but can have a high, maximum size limit configured. If administrators are not careful, disk

arrays can be provisioned too small to accommodate this type of growth.

It can also be easy to overlook I/O performance, and only size volumes for expected capacity. Multiple

high I/O virtual machines can quickly overwhelm a shared VHD volume. In such cases, the best practice is

to spread heavy I/O virtual machines over many volumes, or use directly mapped volumes to control VM

storage performance more directly.

If using System Center 2012 VMM to provision virtual machines through SAN copy, it is important to

remember that these are limited to 1:1 ratio of VM to disk. This restriction is imposed by VMM template

deployment rules, and is covered in more detail in the “System Center 2012 VMM” section.

The following points briefly summarize the Storwize family and SVC volume design.

RAID arrays, called managed disks (MDisks), are created from the available internal

physical disks.

The MDisks are placed in pools, where they are virtualized as extents.

External back-end storage systems from any vendor can also present their own arrays as

MDisks imported into the Storwize or SVC systems as a virtual front end, which are also

placed in pools. This is called external virtualization and it allows other storage systems to

take advantage of centralized management from the Storwize easy-to-use GUI in addition

to the performance benefits from I/O caching, copy services, and striping volumes over

multiple arrays.

Lastly, volumes are provisioned from the available space in these pools, and can either be

sequentially mapped to the physical MDdisks, or striped across multiple MDisks.


7

Figure 3: View of storage pools and volumes

The only method if using the Storwize GUI is striped volumes. This provides the best performance and

provisioning flexibility for most workloads. Provisioning a sequential volume, using the space on only one

MDisk, requires the use of command-line interface (CLI) commands to configure the volumes. As an

example use of sequential volumes, when testing for the Microsoft SQL Fast Track data warehouse

workload, the sequential volumes slightly out-performed stripped volumes. You can find this Fast Track

configuration guide, including scripts for creating and mapping sequential volumes at:

ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102243

Virtual extent size is preconfigured in the new Storwize software to a default of 1 GB. This should not be

confused with volume stripe size, which is 256 KB by default. Consider the following points when

determining the extent size of new storage pools.

The extent size must be specified when the new storage pool is created.

Extent size cannot be changed later.

Storage pools can have different extent sizes.

Pools must have the same extent size to migrate data between them.

The extent size affects the maximum size of a volume in the storage pool.

Figure 4 shows the maximum volume capacity possible for each extent size. The maximum is different for

thin-provisioned volumes because Storwize allocates a whole number of extents to each volume created;

using a larger extent size might increase the amount of storage that is wasted at the end of each thin

volume. Larger extent sizes also reduce the ability of the Storwize V7000 system to distribute sequential

I/O workloads across many MDisks, which reduces the performance benefits of virtualization.


8

Figure 4: Maximum volume sizes per extent

Thin provisioning

Thin provisioning is a technology that has been around awhile and most environments are able to take

advantage of the feature to keep their data storage as efficient as possible, including Hyper-V volumes.

You need to consider a few things to keep the thin provisioned volumes optimized and efficient.

Thin-provisioned volumes have both a virtual (or logical) capacity and a real capacity. The real capacity is

what is actually used by the system and the virtual capacity is its configured maximum size that the

volume can expand to. The real space needs to be monitored and must have warning thresholds

configured to prevent the disk from reaching its full virtual size and shutting down. Another solution to this

is to enable the auto expand feature on the Storwize family or SVC volume.

Although the impact is minor, I/O rates for thin-provisioned disks are slightly slower than fully allocated

volumes, all other things being equal. This is due to the additional processing needed to maintain

metadata information regarding real and virtual space usage.

When creating thin-provisioned volumes on the Storwize family or SVC system, a grain size is specified.

The recommended size is 256 KB. Although smaller grain sizes use less space, they create more

metadata processing and can negatively affect performance. The size of the grain used also affects the

virtual size limit of the volume. A size of 256 KB has been determined to be the best for performance. If

using FlashCopy with thin-provisioned source and target volumes, the volumes must use the same grain

size.

On the Storwize family and SVC systems, thin-provisioned volumes can be converted to fully allocated

volumes and fully allocated volumes in turn can be converted to thin-provisioned volumes.


9

Figure 5: Detailed properties view of thin provisioned volume

One of the administrative concerns with thin provisioning is the need to reclaim space after files are

deleted at the operating system level. If space is not reclaimed, then over a period of time, thin

provisioning loses its efficiency. Windows 2012 uses the SCSI UNMAP command to reclaim space, with

both real-time and manual space reclamation capabilities. The Storwize family systems and SVC systems

do not currently support this method; however, support is expected as a future enhancement. Until then,

as an alternative, there are third-party tools available that can be used to reclaim the space.

Multipathing

Regardless of the connection methods used, it is important to install the IBM SDDDSM to manage

multipath I/O traffic. SDDDSM relies on the Microsoft MPIO feature, and the installer will check for the

feature and install it. This software needs to be installed before mapping any volumes to the server.

You can download the software from the IBM support website, and it is important to download the version

specific to the Storwize or SVC model and operating system version, as cataloged on the IBM website.

You can download the SDDDSM packages at: ibm.com/support/docview.wss?uid=ssg1S4000350

The software installation must be launched from the command line, with administrative permissions by

opening the command line with the Run as option and choosing administrator.

The recommended installation process is to let the SDDDSM installer install the native Microsoft MPIO

feature. Attempts to install with a pre-existing Microsoft MPIO configuration might result in unexpected

errors and conflicts with leftover connections or configurations, depending on the history of the server. The


10

best approach to avoid such issues is to uninstall the Microsoft MPIO feature first, restart, and then start

the SDDDSM installation and allow it to install the Microsoft MPIO component during the process. After the

server restarts, connect the storage and scan for new volumes. Verify that the volumes show up as

expected in Windows Disk Manager.

If the environment is only using volumes mapped to the Hyper-V hosts, such as VHDs, then the multipath

software only needs to be installed on the Hyper-V hosts, and not the virtual machines. However, if there

are direct connections and volume mappings to the virtual machines, then the SDDDSM software must be

installed on the virtual machines. SDDDSM can handle these the same way it manages the physical

server connections.

When volumes are created on the Storwize family or SVC systems, the volumes are alternately assigned a

node owner in a balanced manner. The controller node that owns the volume is considered to be the

preferred path. SDDDSM load-balancing attempts to balance the load across all preferred paths.

SDDDSM uses the path that has the least I/O at the time. If SDDDSM cannot find an available preferred

path, it balances the load across all the paths found and uses the least active non-preferred path.

Note: On Windows Server 2012, there is a Microsoft patch that conflicts with the SDDDSM installation. If

KB2779768 is installed on the server and then SDDDSM is installed, the list of IBM storage devices is not

populated. This is because, the registry key MPIOSupportedDeviceList under MPDEV does not get

properly updated. The issue is being investigated. The workaround is to ensure that SDDDSM is installed

first, and then apply all applicable Microsoft patches. If installed in this order, the issue does not occur.

The other workaround is to import a known good registry key from an unaffected system.

Version of SDDDSM for proof of concept testing: 2.4.3.4-4

SAN zoning

Single initiator zoning is the recommended configuration. In this type of zoning, each host’s host bus

adapter (HBA) port is zoned with two storage ports, one from each Storwize controller. With multiple

storage ports, the zones must rotate the use of the four ports on each controller to balance the load and

performance. The illustration in Figure 6 shows a typical zoning configuration.

Figure 6: Single initiator zoning example

Figure 7 is a simple example of the zones being load balanced across the four ports on each Storwize controller node. In the example, the server has 4 HBA ports, and is balanced across all 8 FC ports on the Storwize system, using both controller nodes (A and B). Each line in the table is a zone.


11

Figure 7: Sample zoning configuration

Virtual machine storage

There are several connectivity options available for Hyper-V on IBM Storwize family and SVC systems.

Volumes can be connected at the Hyper-V host as VHD storage, mapped directly to the virtual machines

or a combination of the two. The direct connections to virtual machines are still using the underlying

physical network or HBA, by creating a virtual connection mapped through these devices. As with any

Hyper-V resource, bandwidth considerations need to be based on the throughput and capabilities of the

physical hardware that the virtual machines rely on. An example of combining the connectivity types is

having the operating system on a VHD, with direct-attached volumes dedicated to a database or similar

heavy I/O or high-throughput application. Whenever high performance is needed, direct attached is the

fastest, whether it is iSCSI, virtual Fibre Channel or pass-through disks.

When using directly connected drives, the volume sizing is configured similar to physical server standards.

The volume is no longer shared with other VHD files, but is a direct application specific volume designed

for capacity and performance accordingly.

Fibre Channel

Fibre Channel connections are used at the Hyper-V host as volumes for VHD files or directly to the virtual

machine. Making direct Fibre Channel connections requires the use of Microsoft’s virtual Fibre Channel

technology. N_Port ID virtualization (NPIV) compliant switches and HBAs can take advantage of virtual

Fibre Channel direct connection mappings to a VM, which was introduced with Windows Server 2012 and

uses Hyper-V virtual SAN switches and HBAs. NPIV is a Fibre Channel feature that allows multiple FC

initiators to occupy a single physical port. You can find more information about virtual Fibre Channel at:


Direct virtual machine connections can also be Fibre Channel connected pass-through disks, which are

less common as newer direct connection options gain popularity.


12

Hyper-V virtual Fibre Channel configuration

This section covers virtual Fibre Channel configuration. Although it is often used as an ideal direct

connection method for shared storage and fail over clustering, it can also be used with stand-alone

Hyper-V hosts. In this example, it is using Microsoft fail over clustering.

Note: NPIV is only supported on Storwize family or SVC systems if connected to a switch that

supports the protocol. NPIV is not supported with direct attached storage configurations (connecting

without a switch).

The IBM mulitpath driver (SDDDSM) must also be installed on each virtual machine, as covered

earlier. The multipathing is managed from within the virtual machine by this software and the Microsoft

MPIO component. SDDDSM can also be installed on the Hyper-V host, and does not create any

conflict.

Since virtual FC is a newer feature, more detailed steps are being shown to configure it. Follow the

steps below to connect a volume with Hyper-V virtual FC switches and HBAs.

1. Open the Hyper-V manager, and in the right panel, click Virtual SAN Manager.

2. Click Create.

3. Enter a name for the virtual SAN switch. Note that the same virtual switch name must be used on

each Hyper-V host server in the host cluster, or migration of the virtual machine will fail.

4. Select the check boxes next to the physical HBA ports to be used. In a typical production

environment, two virtual SAN switches must be configured for redundancy, similar to a typical

physical SAN topology.

5. Click Apply to save the switch configuration.

6. Repeat steps 1 to 5 on the second node of the host cluster, naming the switch the same. This

completes the virtual SAN switch setup. Refer to Figure 8 for a view of the Virtual SAN Manager.


13

Figure 8: Hyper-V virtual FC SAN switch interface

Configure Hyper-V virtual Fibre Channel adapters

Perform the following steps to configure Hyper-V virtual FC adapters.

1. From the Failover Cluster Manager, stop each virtual machine to allow configuration changes.

2. Right-click the virtual machine and click Settings.

3. In the left panel, click Add Hardware, then click Fibre Channel Adapter, and then click Add. This

opens the Fibre Channel Adapter settings screen as shown in Figure 9.


14

Figure 9: Hyper-V virtual Fibre Channel adapter and WWPN address set

4. Select the virtual SAN switch (that you created earlier) from the Virtual SAN list.

5. Use the default worldwide port name (WWPN) and worldwide node name (WWNN) that are

provided. These are used to create NPIV virtual ports on the host automatically when the virtual

machine is started. Each virtual Fibre Channel adapter has two WWPNs assigned to it as an

address set. The virtual ports are automatically removed when the virtual machine is turned off.

Only one virtual port will be active and visible on the physical HBA at a time, however both

WWPNs must be zoned to the storage system. During a live migration, both ports will be in use to

maintain connectivity during the move.

6. Repeat steps 3 to 5 to create any additional adapters.

7. Click Apply to save the configuration.

8. Start the virtual machine. Note that the VM might fail to start if NPIV is not enabled on the HBA,

switch, and individual switch ports. Enable NPIV on the switch ports connecting both the HBAs

and the Storwize or SVC system. It can also fail to start if the switch firmware or HBA drivers are

not at the most recent versions to support NPIV.

9. Using the physical HBA management software on the Hyper-V host server, verify that the virtual

ports are created on the expected physical HBA ports. Figure 10 illustrates the QLogic HBA

command-line utility and shows the virtual ports listed as vPorts.


15

Figure 10: Virtual ports from Hyper-V virtual FC adapters

10. Create a zone on the physical FC switch to enable connectivity between the new vPort WWPN

and the storage. Because only one of the two virtual WWPNs is enabled on the physical HBA at a

time, the second one will not be visibly discovered by the switch. It can be added manually.

Alternately, the position of the WWPNs in the virtual Fibre Channel adapter properties page can

be swapped which results in the other WWPN being created and visible for zoning. It is critical that

both virtual WWPNs are zoned.

11. Create a host definition on the storage system using the vPort WWPNs. Only one of these will be

visible in the Storwize GUI port drop-down list when creating the host. The second one must be

manually added, and will show as unverified. This is fine. The host will also be in a degraded state

as it can only see one of the virtual ports. During a live migration, both ports will become active.

12. Map volumes to the host and verify that multipath is working on the host.

13. Test live migration to verify that the virtual machine migrates without errors.

You can find more detailed information on Microsoft Hyper-V virtual FC features at:


The windows event log provides Hyper-V virtual Fibre Channel specific logging that can be helpful for

troubleshooting virtual FC issues. You can find the log at Applications and Services Logs Microsoft

Windows Hyper-V SynthFC (refer to Figure 11).


16

Figure 11: Hyper-V virtual Fibre Channel event log

There is a limit to the number of Fibre Channel paths supported to a single volume from the Storwize

system to a host server. The number of paths must not exceed the number of Fibre Channel ports on the

storage system. If this is exceeded, then it is considered an unsupported configuration. As an example, on

the IBM Storwize V7000 system, each controller node has four FC ports and each Storwize V7000 system

has two controller nodes, providing a total of eight ports. In this case, without any zoning, the total number

of paths to a volume is eight times the number of host ports. This rule exists to limit the paths that must be

resolved by the multipathing software and to provide a reasonable path failover time. A host port and two

storage ports would result in two paths per zone. The maximum number of volumes supported for a

Window host is 512.

iSCSI

The IBM Storwize family and SVC supports 1Gb and 10Gb iSCSI connections. For 1Gb connections, the

built-in Ethernet ports on the Storwize controllers can be used, including port 1 on each controller, which is

shared as a management port. The Storwize system can assign multiple IP addresses to this port, one for

management and one for iSCSI connections. For the 10Gb connections, the Storwize systems use

expansion cards with 10Gb iSCSI / Fibre Channel over Ethernet (FCoE) ports.

The following section provides more detail on configuring iSCSI connections. It is the same process

regardless of physical or virtual server.


17

Microsoft failover clustering is supported with iSCSI, with some limitations, as listed in the following IBM

support page: ibm.com/support/docview.wss?uid=ssg1S1004450. Information on this page is indexed by

the operating system and protocols, and provides detailed compatibility listings.

Jumbo frames should be enabled and the maximum transmission unit (MTU) set to 9000 (or 9014

depending on the hardware) when setting the virtual network interface cards (NICs) as shown below. The

method for setting this is the same on both the physical and virtual NICs.

Figure 12: Configuring jumbo frames on network card

This can improve performance significantly. When enabling this, it must be done at all points along the

data path – physical and virtual NICs, storage, and the physical switch. There is no configuration needed

on the Hyper-V virtual switch; it automatically senses MTU sizes.

To configure jumbo frames on the Storwize family and SVC systems, use the cfgportip CLI command:

cfgportip –mtu <value> -iogrp <iogroupid> <id>

For example:

cfgportip -mtu 9000 -iogrp 0 1

After configuring the components, verify that the jumbo frames are set up correctly by pinging the storage

IP with an 8k packet from the Hyper-V server or guest VM, as follows:

Ping <storage iSCSI port IP> -f –l 8000

If the replies are received with bytes=8000, then jumbo frames are configured correctly. Technically, the

ping test might be as large as 8972, which is 9000 minus wrappers and associated packet structures.

For the most up-to-date information on configuring iSCSI with Storwize systems, refer to:

ibm.com/partnerworld/wps/servlet/ContentHandler/stg_ast_sto_wp_best-practices-with-ibm-

storwize-v7000

http://pic.dhe.ibm.com/infocenter/storwize/ic/index.jsp?topic=%2Fcom.ibm.storwize.v7000.doc%2

Fsvc_rulesiscsi_334gow.html


18

FCoE

Fibre Channel over Ethernet takes advantage of the latest 10Gb networking to run the Fibre Channel

protocol for block storage on 10Gb Ethernet cables. The servers connect to a supported converged switch

using converged networking adapter (CNA) cards, with each card providing the operating system both a

network port and a Fibre Channel port. The Storwize family systems connect to the converged networking

switch through the 10Gb expansion cards in the storage controllers. These expansion card ports are used

for either 10Gb iSCSI or FCoE.

FCoE configurations need to be using supported CNA cards, switches, and firmware levels. You can find

the supported hardware and software levels at: ibm.com/support/docview.wss?uid=ssg1S1004450

This link has an indexed list sorted by operating systems and protocols. This link is specific to Storwize

V7000, but there are similar pages available for the other Storwize models. Because the Storwize systems

all run similar architecture and protocols, what is true about one model usually applies to the others.

Although other combinations of cards and switches might work, if they are not listed on the page, they

have not been tested.

For FCoE connections, the ports need to be zoned with the 10Gb storage ports on the converged switch,

then a Fibre Channel host definition can be created on the Storwize system. The host creation, mapping of

drives, and drive initialization on the host server is similar to any other Fibre Channel connected drive.

FCoE is supported at the Windows Hyper-V host level and as such supports Hyper-V virtual hard drives

hosted on the Hyper-V host server’s volumes. There is no direct-attached option with FCoE, other than the

use of pass-through disks, which are volumes mounted on the Hyper-V host server and mapped directly to

a virtual machine.

Although Microsoft failover clustering supports FCoE, Microsoft clustering with FCoE is not currently

supported with Storwize family systems and SVC at the time of this writing. As a result, Hyper-V systems

are currently limited to stand-alone configurations. Support for clustering with FCoE should be available at

a later date, and the link can be checked for updates on supported configurations. If your environment

requires clustering support with FCoE, contact your IBM representative for updated information on support

availability options.

VHD volumes

The most common storage for virtual machines is the volume on the Hyper-V host server where virtual

hard drive files are stored. In many cases, these are configured as cluster shared volumes, because a

typical Hyper-V environment consists of multinode high availability clusters, with the volume presented to

multiple hosts and access controlled by the Windows disk and cluster management features.

VHD files are connected as either IDE or SCSI controller devices in Hyper-V. Boot disks must use

integrated drive electronics (IDE). SCSI disks are the more scalable method, which supports multiple disks

per controller. Each VM can have four SCSI controllers with 64 disks per controller. As a result, the

recommended method for adding additional VHD storage to a VM is SCSI. Of course, the SCSI connected

device can be either a VHD or a physical drive.


19

For heavy I/O applications, multiple SCSI adapters used to be the norm to avoid bottlenecks due to limited

channels, queue depths, and processor storage I/O interrupt management of each SCSI adapter.

However, with Windows Server 2012, additional storage performance was gained by adding channels,

with the interrupt management distributed over all virtual processors. As a result, the use of multiple virtual

SCSI adapters is usually not needed.

VHD files can be either fixed or dynamically expanding. There are some impacts to storage provisioning

depending on the type of VHD used. One of the impacts is on thin provisioning. Placing a fixed size VHD

on a thin provisioned disk results in the full VHD file size being written to the volume, which can take time

but results in better performance once it is written to disk due to the processing associated with dynamic

expansion. If storage efficiency is more important than performance, then use dynamic expanding VHDs.

These disks will not allocate all storage that is specified for them, but rather dynamically allocate it as

needed. There will be more processing with the ongoing expansion, but the virtual drive and the thin-

provisioned volumes will only use space as needed.

Windows 2012 introduced the VHDX virtual hard drive format. These can also be fixed or dynamic;

however, the dynamic format VHDX addresses most of the performance concerns that existed with

Windows 2008. As a result the performance of dynamic VHDXs are much closer to that of fixed VHDXs.

However, if maximum storage I/O performance is needed, using fixed VHDX files is still recommended.

VHDX supports larger volume sizes, up to 64 TB and offer improved protection against data corruption by

logging updates to VHDX metadata files. New virtual hard disks should use the VHDX format whenever

possible to take advantage of the new features and capabilities.

Another performance-related concern with dynamic virtual hard drives over fixed ones is available

capacity. The dynamic volumes can fill up the defined space and shut down if administrators or monitoring

solutions are not watching the capacity levels and trends closely.

As virtual machines are migrated to Windows Server 2012, consider converting VHDs to VHDX format to

take advantage of the improved performance and capabilities.

SAS

Some of the newer Storwize systems support SAS host connectivity. For example the IBM Storwize V3700

and V5000 systems come with four 6Gb SAS ports for host connectivity. SAS connections are direct

attached only. On Storwize systems that support SAS host connections, the new host wizard in the

Storwize management GUI includes an option for a SAS host, and new CLI commands to support SAS

host and port management from the command line.

Direct attached

Although in most cases, SAN-attached hosts are the recommended approach, most of the Storwize family

systems now support direct-attached hosts. Direct-attached storage offers smaller environments a less-

complex and lower-cost starting point, with the option to expand to SAN-attached, as needed later.

When directly attaching, the host needs to make one or more connections to each controller node in the

Storwize system to provide redundant I/O paths.


20

Refer to the SSIC link provided earlier to determine the most recent information regarding which systems

and protocols support direct host connections.

Pass-through disks

Pass-through disks provide one of the better performance storage options, similar to iSCSI or virtual Fibre

Channel. If the systems support it, virtual Fibre Channel is the recommended direct connection method for

the best performance. However, if the systems do not support virtual Fibre Channel, then pass-through

disks provide a good alternative.

Pass-through disks are volumes presented originally to the Hyper-V host servers, and kept offline to the

host server, with control and connectivity passed into the virtual machine. The virtual machine uses a

virtual SCSI controller to connect the pass-through disk. Up to 64 disks can be connected per virtual SCSI

controller. Up to four SCSI controllers can be configured per virtual machine. So, clearly, this is a good

option for storage performance and scalability in larger systems. After the pass-through disks are

connected, they are configured similar to a disk on a physical server.

It is possible to use the pass-through disk as a boot disk for the operating system. This requires the pass-

through disk to be set up before installing the operating system, and must be connected as an IDE

controller device instead of the usual SCSI device.

Hyper-V CSV Cache

Hyper-V introduced CSV Cache with Windows Server 2012 to improve storage performance by using

system memory (RAM) as a write-through cache. This can improve read request performance, while write-

through results in no caching of write requests. Up to 20% of RAM can be allocated for Windows Server

2012, and up to 80% with Windows Server 2012 R2. CSV Cache is built into the Failover Clustering

feature, which manages and balances the performance across all nodes in the cluster. The recommended

value is 512 MB, which is a good starting point. Additional testing needs to be done with larger settings to

validate the best performance setting for the environment.

You can find more detailed information from Microsoft at:

http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx

Hyper-V clustering

High availability for virtual machines is accomplished by using Windows Failover Clustering and shared

storage. The virtual machine and files are cluster resources that reside on shared storage which can fail

over between multiple Windows Hyper-V host cluster nodes. After a Hyper-V VM has been made highly

available, it must be managed from the failover cluster manager. Although this level of clustering at the

Hyper-V parent or host-level protects the virtual machine and its related resources, it does not necessarily

protect the operating system or the applications running on the VM. This is where guest clustering can be

very valuable.


21

Figure 13: View of highly available virtual machines in Microsoft Fail Over Cluster Manager

Guest clusters

Clustering of Hyper-V guests adds another layer of clustering to protect the applications and operating

system running on the virtual machines. The virtual machines become cluster nodes, which access directly

connected shared storage. Not all storage types support this feature. The available storage methods are

limited to iSCSI if running Windows Server 2008 or Windows Server 2012, or virtual Fibre Channel for

Windows Server 2012. Pass-through or virtual hard disks cannot be used for guest clustering.

Virtual machine migrations

Most Hyper-V environments take advantage of VM migration capabilities. Although quick migrations are

still used, they can result in some downtime and require a state save to disk. The live migration feature

allows VMs to be moved without any downtime and minimal performance impact. It requires a well-

connected dedicated network to be successful. If using virtual disks for live migration, CSVs are

recommended. However, pass-through disks, standard virtual disks, virtual Fibre Channel and iSCSI are

all supported.

Virtual machine sprawl is very common in today’s virtualized environments. It is easy for IT departments to

start creating a lot of VMs rather quickly out of convenience without factoring in the performance impact.

Moving virtual machines to alternate infrastructure resources is a common administrative task with

Hyper-V, whether it be moving a VM to another node to balance out performance or moving a VM’s files to

different storage. This section covers the storage migration for VMs and the different ways to accomplish

this.


22

Hyper-V storage live migration

With Windows 2012, Hyper-V VHD files can be nondisruptively migrated to different storage using either

the Hyper-V manager or the Windows failover cluster manager. The migration can also be initiated from

System Center 2012 VMM. During the migration copy process, the I/O continues to be routed to the

source location. After the copy is complete, I/O is mirrored to both locations and after fully synchronized, it

is directed only to the target VM file. Finally, the original VM file is deleted. With this new feature, it is no

longer necessary to take a virtual machine offline to move the machine’s VHD file to another storage

location.

Storwize seamless data migration

Another benefit of the IBM Storwize and SVC family systems is the ability to seamlessly migrate volumes

that are having performance issues or need maintenance to more adequately sized storage pools. This

process resolves overloaded disk performance issues quickly without interrupting or making any changes

to the production systems.

Relocating data is one of the most common causes of downtime. The Storwize family and SVC systems

have virtualized the data, which allows the underlying physical changes without interrupting host access or

performance. As a result, applications stay online during common storage maintenance or movement

activities.

The application of this feature for Hyper-V means any storage used by virtual machines or the Hyper-V

hosts can be moved quickly to different storage pools as needed. The performance and capacity of virtual

machines can be constantly changing with the business needs. Sometimes, slower disks are needed; and

other times, it is more space, higher performance, load balancing, or just a maintenance window that is

needed.

Figure 14: View of volume migration to another storage pool


23

Resource metering

A new addition to Windows Server 2012 Hyper-V is resource metering. This tracks and gathers data about

the physical processor, memory, network, and storage used by each virtual machine. By allowing

administrator’s in-depth data on virtual machine resource utilization, they can detect hot spots and

bottlenecks and avoid outages.

This data can be used to plan capacity, track usage of resources by business unit for chargeback, or

analyze the costs of a particular workload. Additionally, the movement of virtual machines such as live,

offline or storage migrations does not affect the measurements. The metering is accomplished with either

PowerShell commands or through APIs in the virtualization WMI provider.

Available measurements include:

Average CPU usage, in MHz

Average physical memory usage, in MB

Minimum memory usage (lowest physical memory)

Maximum memory usage (highest physical memory)

Maximum amount of disk space used by each virtual machine

Total inbound network traffic, in MB, by virtual network adapter

Total outbound network traffic, in MB, by virtual network adapter

System Center 2012 VMM

Microsoft System Center 2012 VMM SP1 provides private cloud management ease and deep functionality,

allowing system administrators to perform common server and storage tasks from a single graphical

interface. Figure 15 shows a view of the VMM management console. You can find more information about

VMM features and capabilities at:

http://technet.microsoft.com/en-us/library/gg610610.aspx


24

Figure 15: System Center 2012 SP1 Virtual Machine Manager interface

The IBM Storwize family products and SVC fully support integration with System Center 2012 VMM and

are compliant with SMI-S standards that VMM relies on. Unlike many SMI-S providers, a separate

installation or management system is not needed with the IBM SMI-S provider because it runs on the

Storwize system, included with Storwize software version 7.0 and later. This single-tier design simplifies

setup and administration, allowing direct communication between VMM or other storage management

applications.

You can find detailed information on IBM storage integration with SMI-S and Common Information Model

(CIM) at:

http://pic.dhe.ibm.com/infocenter/strhosts/ic/index.jsp?topic=%2Fcom.ibm.help.strghosts.doc%2Fhsg_smi

-s_main.html

The high-level steps to set up System Center 2012 VMM with Storwize family or SVC systems includes:

Preparing the VMM server to make sure that VMM can communicate with the storage.

This includes some registry and Microsoft patch changes.

Discovering and connecting the storage system. This involves creating a connection to the

Storwize or SVC system.

Classifying storage levels, based on performance tiers or RAID types.

Allocating storage to Hyper-V host groups. Before using VMM to provision storage for

virtual machines, the storage pools must be allocated to host groups.

After these steps are completed, the solution is ready to start provisioning storage for Hyper-V hosts from

the VMM console.


25

There is another IBM solution guide that covers this configuration in depth for Storwize and SVC systems,

and you can find the paper at:

ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102408

Backup

There are several options to consider when discussing Hyper-V backup planning. A backup can capture

an entire virtual machine, as a point-in-time snapshot of the entire system. This type of snapshot can be

initiated from the Hyper-V manager or VMM.

Figure 16: Hyper-V Manager virtual machine snapshot

However, backup software can also back up applications within the virtual machine, known as application-

aware backups. Often, both methods are combined to provide the highest level of integrity and data

recovery. For most Microsoft environments and applications, VSS is the preferred and often only backup

method supported. VSS providers can be both software and hardware based. Most solutions make use of

hardware-based VSS if it is available, as it allows the storage system to do the heavy lifting, rather than

the operating system.

For Hyper-V, the IBM VSS Hardware Provider supports installation within the VM and provides VSS

snapshot capability of direct-attached volumes just like a physical server. These are application-aware

backups, using a VSS requestor and the application writer such as Exchange or SQL Server to coordinate

the snapshots. IBM provides a proven VSS backup solution with IBM Tivoli® Storage FlashCopy®

Manager.


26

IBM FlashCopy

The FlashCopy function of Storwize family and SVC systems creates point-in-time snapshots of entire

volumes. The data is available immediately on the target volume. Although it takes some time to complete

fully, the result is a full clone of the source volume. The copies are available immediately for read and write

operations. FlashCopy works with normal or thin provisioned volumes – for either source or target

locations.

FlashCopy is fully compatible with the Microsoft VSS framework to coordinate snapshots between backup

requestors, application writers, and software or hardware providers. IBM supports hardware VSS

operations with the IBM VSS Hardware Provider.

There are several methods available for creating snapshots, such as copy-on-write, redirect-on-write, split

mirror, and so on. IBM FlashCopy uses a unique method of copy-on-write with background copy. This

provides both an immediate copy of the data, and a full clone or copy after the background copy is

complete. The time it takes for the background copy to finish depends on the copy rate, and what other

loads are occurring on the storage system. The copy rate can be set between 0 and 100, with the default

set to 50. This is recommended to balance the speed of copying and minimizing impact on the storage

system resources. If faster copies are required, the copy rate can be set closer to 100; however, storage

performance must be monitored to ensure impact on other storage operations.

For Hyper-V environments, the important thing to remember is that this or any snapshot technology snaps

the entire volume. If it is a volume used to store VHDs, or any other multiple files systems, it is taking a

snapshot of everything. When restoring the data, it overwrites everything that is on the disk. As a result,

the recommendation when using snapshots is to use directly connected dedicated volumes for data

locations to ensure other data is not over-written during restores. Some snapshot backup software, such

as Tivoli Storage FlashCopy Manager allows a hybrid approach where the entire volume is captured,

however still allows granular restore of data, thereby avoiding the otherwise full volume overwrite.

Tivoli Storage FlashCopy Manager

Backing up business-critical applications running on virtual machines has often been a hurdle for IT

administrators. IBM Tivoli Storage FlashCopy Manager meets this challenge with support for hardware-

assisted snapshots within Hyper-V guest machines using IBM VSS Hardware Provider and the IBM

Storwize family products and SVC. This provides application-aware VSS backup capability for Hyper-V

guests, with the VSS Hardware Provider and FlashCopy Manager running on the guest machine as if it

were a physical server.

Figure 17 shows a sample configuration of FlashCopy Manager backup for Exchange servers running on

Hyper-V virtual machines.


27

Figure 17: FlashCopy Manager Hyper-V configuration

Figure 18 View of FlashCopy Manager GUI


28

FlashCopy Manager provides a feature rich graphical interface and full command-line capabilities. Error!

Reference source not found. shows a view of the FlashCopy Manager GUI and an Exchange

environment.

Another IBM solution guide is available that covers FlashCopy Manager configuration with Hyper-V. The

paper can be found at: ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102328

Easy Tier

The Storwize family and SVC systems include a feature called IBM System Storage Easy Tier that

dynamically move hot data to faster performing SSDs, and back again when the data becomes cold. Using

a complex algorithm built into the Storwize and SVC software, the system starts monitoring data patterns

over a period of time and then after the most active data is identified, it is migrated to SSDs.

To activate Easy Tier, an existing storage pool made up of traditional disks just needs an SSD MDisk

added to the pool. The pool then becomes a hybrid pool, and Easy Tier is automatically activated at this

point. As soon as the SSD MDisks are added, Easy Tier starts measuring performance in preparation for

data block migrations. By default, the monitoring process runs for about 24 hours before data starts

migrating.

When sizing Hyper-V storage pools, spread the virtual machine storage resources out over several pools.

Place the heavy I/O virtual machine storage in a pool or group of pools that will have SSDs added to it.

Then add an equal amount of SSDs to each pool to spread out the benefit evenly. If many virtual servers

are pulling from one pool, only a percentage of the servers can benefit from the SSDs, as they contend for

SSD resources. For large mail servers, for example, the pools might be configured for only one server per

pool, to ensure that each server can benefit from Easy Tier and the SSDs in each pool evenly.

Easy Tier also has a monitoring mode that can be enabled at the storage pool level that measures the

data and predicts the performance gains that can be expected. This provides an opportunity to plan and

weigh the cost benefits of SSDs before actually purchasing and installing them in the system.

The monitoring measurements are predictions, and the actual benefit can vary depending on how the data

is structured and the system is configured. Before deploying Easy Tier in production, the configurations

need to be tested in a lab or a preproduction sandbox environment to validate the distribution of SSD

design and corresponding performance gains.

IBM Real-time Compression

Beginning with Storwize and SVC software version 7.1 and later, IBM Real-time Compression™ is

included and implemented by simply creating a compressed volume, which is a new type of volume. This

feature uses the Random Access Compression Engine (RACE), previously implemented in the IBM Real-

time Compression Appliance™, which compresses inbound data before it is written to disk.

Since Real-time Compression is defined at the volume level, any Hyper-V virtual hard drives hosted on the

volume are compressed. Of course, direct-attached disks can also be provisioned as compressed

volumes.


29

Figure 19: Creating a new compressed volume

Data can be compressed by up to 80%, allowing up to five times data storage as in the same physical

space. The compression can be used with live and heavy I/O applications such as databases or email,

and it occurs in real time without a queue of uncompressed data waiting to be processed. What all of this

means is no performance impact and very dense storage for a better storage return on investment (ROI).

With Hyper-V and other virtualization solutions, testing has shown compression ratios in the 45% to 75%

range, depending on the workload. File systems that contain data that is already in a compressed format

such as audio, video, and compressed files are not good candidates for Real-time Compression, as the

benefits would be minimal. It would be similar to placing a number of compressed format multimedia files

in a compressed file and the end result might not be much improvement. Because databases store data in

tables, these types of files are good candidates for a compressed volume, with expected compression

ratios around 50% to 80%. When it comes to Hyper-V, the benefits are going to be in line with the target

workload, similar to the way a physical server benefits.

It is possible to predict the compression benefits by using a new IBM utility called the Comprestimator.

This is a command-line utility that uses a highly complex statistical algorithm to sample and predict

compression ratios for a given workload on the sampled volumes. You can find details about the

Comprestimator download and additional information at:

ibm.com/support/docview.wss?uid=ssg1S4001012


30

Conclusion

This paper summarizes the Storwize family products and SVC capabilities and configurations with

Microsoft Windows Server 2012 and Hyper-V. The reliability and performance of the Storwize family

products and SVC with Microsoft workloads has been proven by customer deployments and involvement

with partner testing programs such as SQL Server I/O Reliability, SQL Server Fast Track, Hyper-V Fast

Track and the Exchange Solution Reviewed Program. IBM virtualized storage systems combined with the

wide capabilities of Hyper-V and System Center 2012 VMM provide an efficient and simplified

virtualization solution for today’s budget conscious data centers. Refer to the “Resources” section for

additional detailed information.


31

Resources

The following websites provide useful references to supplement the information contained in this paper:

IBM Systems on PartnerWorld

ibm.com/partnerworld/systems

IBM Storwize family products

ibm.com/systems/storage/storwize/

IBM SAN Volume Controller

ibm.com/systems/storage/software/virtualization/svc/

IBM Redbooks

ibm.com/redbooks

IBM Publications Center

www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US

IBM System x servers

ibm.com/systems/x/index.html

Microsoft TechNet: Hyper-V architecture and features overview


Microsoft TechNet: General System Center 2012 VMM overview and support

http://technet.microsoft.com/en-us/library/gg610610.aspx

https://twitter.com/


32

Trademarks and special notices

© Copyright IBM Corporation 2014.

References in this document to IBM products or services do not imply that IBM intends to make them

available in every country.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business

Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked

terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these

symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information

was published. Such trademarks may also be registered or common law trademarks in other countries. A

current list of IBM trademarks is available on the Web at "Copyright and trademark information" at

www.ibm.com/legal/copytrade.shtml.

Microsoft, Windows, SQL Server, Windows NT, and the Windows logo are trademarks of Microsoft

Corporation in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

Information is provided "AS IS" without warranty of any kind.

All customer examples described are presented as illustrations of how those customers have used IBM

products and the results they may have achieved. Actual environmental costs and performance

characteristics may vary by customer.

Information concerning non-IBM products was obtained from a supplier of these products, published

announcement material, or other publicly available sources and does not constitute an endorsement of

such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly

available information, including vendor announcements and vendor worldwide homepages. IBM has not

tested these products and cannot confirm the accuracy of performance, capability, or any other claims

related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the

supplier of those products.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice,

and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the

full text of the specific Statement of Direction.

Some information addresses anticipated future capabilities. Such information is not intended as a definitive

statement of a commitment to specific levels of performance, function or delivery schedules with respect to

any future products. Such commitments are only made in IBM product announcements. The information is

presented here to communicate IBM's current investment and development activities as a good faith effort

to help with our customers' future planning.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled

environment. The actual throughput or performance that any user will experience will vary depending upon

considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the

storage configuration, and the workload processed. Therefore, no assurance can be given that an

individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

Photographs shown are of engineering prototypes. Changes may be incorporated in production models.

http://www.ibm.com/legal/copytrade.shtml


33

Any references in this information to non-IBM websites are provided for convenience only and do not in

any manner serve as an endorsement of those websites. The materials at those websites are not part of

the materials for this IBM product and use of those websites is at your own risk.

microsoft hyper v with ibm san volume controller and ibm...

Documents