Hyper - V Getting Started

Hyper-V Release Notes
Applies To: Windows Server 2008
These release notes address known issues about Hyper-V. For other information, see Hyper-V.
Known Issues
The following are the known issues for the release of Hyper-V distributed as ”Hyper-V Update
for Windows Server 2008 x64 Edition” (KB950050) (http://go.microsoft.com/fwlink/?
LinkId=139066). For known issues related to subsequent releases of Hyper-V, see the release
notes for Windows Server.
Backup
 The data on the physical disk attached to a virtual machine, or on the Internet SCSI
(iSCSI) disk attached to the guest operating system will not be included in backup when a
virtual machine has either a physical disk or an iSCSI disk attached. To fix this issue,
utilize backup agents inside the virtual machine and individually back up each virtual
machine as if it is a physical computer.
 Virtual machines that have dynamic volumes inside the guest operating system are
supported for offline backup only when the guest operating system is configured to use
dynamic disks in Disk Manager. When attempting a backup of such a virtual machine, it
is saved and subsequently resumed, during the backup process. Even if the virtual
machine is running, only an offline backup is taken. To avoid this issue, when using
online backup, one should only use a basic disk. To fix this, either use offline backups or
convert the dynamic disk to a basic disk.
 If you restore a Volume Shadow Copy Service (VSS) based backup of a virtual machine
while it is running, the virtual machine may end up in an inconsistent state. To avoid this
issue, ensure that the running virtual machine is not selected in the backup application
before starting the VSS restore operation, ensure that the virtual machine is turned off
prior to starting the VSS restore operation or, if doing a system-wide restore, ensure that
all of the virtual machines are turned off.
Security
 If the Hyper-V authorization store is located in Active Directory, then the removal of a
user from a role does not take immediate effect. Either the server running Hyper-V (the
computer that runs the Virtual Machine Management Service (VMMS)) or Active
Directory needs to be rebooted to apply the changes. To avoid this issue, use an XML file
as the store type. To fix this issue, reboot the Hyper-V server hosting VMMS, restart
VMMS and Network Virtual Service Provider Windows Management Instrumentation
(NVSPWMI) services or reboot Active Directory.
Operations
 If you try to restart or reset a virtual machine when the physical computer is low on
available memory, the virtual machine may be turned off instead of restarted. To avoid
this issue, retain at least 512 MB of memory for use only on the physical computer. To
fix this issue, you can try to start the virtual machine. If this does not work, you can
modify the virtual machine settings to reduce the amount of memory assigned to the
virtual machine.
 While connecting through Virtual Machine Connection under a Remote Desktop session,
the use of CTRL+ALT+DEL will not work. To avoid this, use CTRL+ALT+END,
avoid using Virtual Machine Connection under Remote Desktop or use the
CTRL+ALT+DEL options found on both the toolbar and Action menu.
 You may encounter issues when attempting to attach virtual hard disks (VHDs) and ISOs
to a virtual machine from a network share. To avoid this issue, ensure that both the
Hyper-V server and the network server are members of the same domain. The network
share requires read access for ISOs and read/write access for VHDs for both the user and
computer account of the server running Hyper-V. If you are attempting this from a third
computer (not utilizing the user interface on the server running Hyper-V), constrained
delegation for Server Message Block (SMB) between the server running Hyper-V and the
network file server must be enabled.

o




Hyper-V Getting Started Guide
 Hyper-V Update List for Windows
Server 2008
 Hyper-V Update List for Windows
Server 2008 R2
 Hyper-V: Using Hyper-V and Failover
Clustering
 Hyper-V: Using Live Migration with
Cluster Shared Volumes in Windows
Server 2008 R2
 Planning
 Installation
 Configuration
 Migration
 Hyper-V Videos
 Network Load Balancing
 Networking
 Performance and Reliability
 Print and Document Services
Remote Desktop Services (Terminal Services)

Security and Protection

Storage

Streaming Media Services

Web Server (IIS)

Windows Deployment Services

Windows Search, Browse, and Organization

 Windows Server 2008 R2 Solutions
 Windows Server 2008 Foundation
 Windows Server 2003
 Windows 2000 Server
 Windows Essential Business Server
 Windows HPC Server
 Windows MultiPoint Server
 Windows Small Business Server
 Windows Server Storage Solutions
o More...
o TechNet Archive
TechNet
TechNet Library
Windows Server
Windows Server 2008 and Windows Ser...
Browse Windows Server Technologies
Hyper-V
Getting Started
Hyper-V Getting Started Guide

Updated: July 1, 2009
Hyper-V™ is a role in Windows Server® 2008 that provides you with the tools and services you
can use to create a virtualized server computing environment. This type of environment is useful
because you can create and manage virtual machines, which allows you to run multiple operating
systems on one physical computer and isolate the operating systems from each other. This guide
introduces Hyper-V by providing instructions for installing this role and configuring a virtual
machine.
In this guide
Requirements for Hyper-V
Step 1: Install Hyper-V
Step 2: Create and set up a virtual machine
Step 3: Install the operating system and integration services
Step 4: Configuring virtual networks
Requirements for Hyper-V

Hyper-V has specific requirements. Hyper-V requires an x64-based processor, hardware-assisted
virtualization, and hardware data execution prevention (DEP). Hyper-V is available in x64-based
versions of Windows Server 2008—specifically, the x64-based versions of Windows
Server 2008 Standard, Windows Server 2008 Enterprise, and Windows Server 2008 Datacenter.
For more information about the requirements, see the Hyper-V installation prerequisites
(http://go.microsoft.com/fwlink/?LinkId=122183).
Known issues
Known issues are described in the release notes. We recommend that you review the release
notes before you install Hyper-V.
To download the Hyper-V release notes, see http://go.microsoft.com/fwlink/?LinkId=98821. The

release notes are also available in the Windows Server 2008 Technical Library
Step 1: Install Hyper-V

Note
Before you install Hyper-V, verify that your computer has been updated with the
release version of Hyper-V. The release version (RTM) of Windows Server 2008
included the pre-release version of Hyper-V. The release version of Hyper-V is
offered through Windows Update as a recommended update, ‘Hyper-V Update for
Windows Server 2008 x64 Edition (KB950050)’. However, you also can obtain the
update through the Microsoft Download Center. To download this update, see
http://go.microsoft.com/fwlink/?LinkId=123539. To determine whether the update
has been applied to your computer, do one of the following:
 On a full installation of Windows Server 2008, click Start, click Windows

Update, click View update history, and then click Installed Updates.
 On a Server Core installation, at the command prompt, type:
wmic qfe list

Look for update number kbid=950050, which indicates that the update for
Hyper-V has been installed.
You can install Hyper-V on either a full installation or a Server Core installation. You can use
Server Manager to install Hyper-V on a full installation, as described in the following procedure.
To install on a Server Core installation, you must perform the installation from a command
prompt. Run the following command:
Start /w ocsetup Microsoft-Hyper-V
Note
To manage Hyper-V on a Server Core installation, you can use the Hyper-V
management tools to manage the server remotely. The management tools are
available for Windows Server 2008 and Windows Vista Service Pack 1. For more
information, see article 950050 (http://go.microsoft.com/fwlink/?LinkId=122188) and
article 952627 (http://go.microsoft.com/fwlink/?LinkId=122189) in the Microsoft
Knowledge Base.
To install Hyper-V on a full installation of Windows Server 2008
1. Click Start, and then click Server Manager.

2. In the Roles Summary area of the Server Manager main window, click Add Roles.
3. On the Select Server Roles page, click Hyper-V.
4. On the Create Virtual Networks page, click one or more network adapters if you want
to make their network connection available to virtual machines.
5. On the Confirm Installation Selections page, click Install.
6. The computer must be restarted to complete the installation. Click Close to finish the
wizard, and then click Yes to restart the computer.
7. After you restart the computer, log on with the same account you used to install the role.
After the Resume Configuration Wizard completes the installation, click Close to finish
the wizard.
Step 2: Create and set up a virtual machine

After you have installed Hyper-V, you can create a virtual machine and set up an operating
system on the virtual machine.
Before you create the virtual machine, you may find it helpful to consider the following
questions. You can provide answers to the questions when you use the New Virtual Machine
Wizard to create the virtual machine.
 Is the installation media available for the operating system you want to install
on the virtual machine? You can use physical media, a remote image server,
or an .ISO file. The method you want to use determines how you should
configure the virtual machine.
 How much memory will you allocate to the virtual machine?
 Where do you want to store the virtual machine and what do you want to
name it?
To create and set up a virtual machine
1. Open Hyper-V Manager. Click Start, point to Administrative Tools, and then click
Hyper-V Manager.
2. From the Action pane, click New, and then click Virtual Machine.
3. From the New Virtual Machine Wizard, click Next.
4. On the Specify Name and Location page, specify what you want to name the virtual
machine and where you want to store it.
5. On the Memory page, specify enough memory to run the guest operating system you
want to use on the virtual machine.
6. On the Networking page, connect the network adapter to an existing virtual network if
you want to establish network connectivity at this point.
Note
If you want to use a remote image server to install an operating system on your test
virtual machine, select the external network.
7. On the Connect Virtual Hard Disk page, specify a name, location, and size to create a
virtual hard disk so you can install an operating system on it.
8. On the Installation Options page, choose the method you want to use to install the
operating system:
o Install an operating system from a boot CD/DVD-ROM. You can use
either physical media or an image file (.iso file).
o Install an operating system from a boot floppy disk.
o Install an operating system from a network-based installation server.

To use this option, you must configure the virtual machine with a
legacy network adapter connected to an external virtual network. The
external virtual network must have access to the same network as the
image server.
9. Click Finish.
After you create the virtual machine, you can start the virtual machine and install the operating
system.
Step 3: Install the operating system and integration services
In the final step of this process, you connect to the virtual machine to set up the operating
system. As part of the setup, you install a software package that improves integration between
the virtualization server and the virtual machine.
Note
The instructions in this step assume that you specified the location of the installation
media when you created the virtual machine. The instructions also assume that you
are installing an operating system for which integration services are available.
To install the operating system and integration services
1. From the Virtual Machines section of the results pane, right-click the name of the virtual
machine you created in step 2 and click Connect. The Virtual Machine Connection tool
will open.
2. From the Action menu in the Virtual Machine Connection window, click Start.
3. Proceed through the installation.
Notes
o When you are at the point where you need to provide input to
complete the process, move the mouse cursor over the image of the
setup window. After the mouse pointer changes to a small dot, click
anywhere in the virtual machine window. This action "captures" the
mouse so that keyboard and mouse input is sent to the virtual
machine. To return the input to the physical computer, press
Ctrl+Alt+Left arrow and then move the mouse pointer outside of the
virtual machine window.
o After the operating system is set up, you are ready to install the
integration services. From the Action menu of Virtual Machine
Connection, click Insert Integration Services Setup Disk. On
Windows operating systems, you must close the New Hardware Wizard
to start the installation. If Autorun does not start the installation
automatically, you can start it manually. Click anywhere in the guest
operating system window and navigate to the CD drive. Use the
method that is appropriate for the guest operating system to start the
installation package from the CD drive.
After you have completed the setup and integration services are installed, you can begin using
the virtual machine. You can view or modify the virtual hardware that is configured for the
virtual machine by reviewing the settings of the virtual machine. From the Virtual Machines
pane, right-click the name of the virtual machine that you created in step 3 and click Settings.
From the Settings window, click the name of the hardware to view or change it. For more
information, see Configuring Virtual Machines (http://go.microsoft.com/fwlink/?
LinkId=122190).
Step 4: Configuring virtual networks

You can create virtual networks on the server running Hyper-V to define various networking
topologies for virtual machines and the virtualization server. There are three types of virtual
networks: a private network, which provides communication between virtual machines only, an
internal network, which provides communication between the virtualization server and virtual
machines, and an external network, which provides communication between a virtual machine
and a physical network by creating an association to a physical network adapter on the
virtualization server.
The following procedures provide the basic instructions for configuring virtual networks. For
more information about designing and deploying virtual networks, see the deployment content
for Hyper-V at the Windows Server 2008 TechCenter (http://go.microsoft.com/fwlink/?
LinkID=108560).
To create a virtual network
1. Open Hyper-V Manager.

2. From the Actions menu, click Virtual Network Manager.
3. Under Create virtual network, select the type of network you want to create. The types
of network are External, Internal, and Private. If the network you want to create is an
external network, see “Additional considerations” below.
4. Click Add. The New Virtual Network page appears.
5. Type a name for the new network. Review the other properties and modify them if
necessary.
Note
You can use virtual LAN identification as a way to isolate network traffic.
However, this type of configuration must be supported by the physical
network adapter. For information about configuring virtual LAN identification,
see the Hyper-V deployment content at the Windows Server 2008 TechCenter
(http://go.microsoft.com/fwlink/?LinkID=108560).
6. Click OK to create the virtual network and close Virtual Network Manager, or click
Apply to create the virtual network and continue using Virtual Network Manager.
To add a network adapter to a virtual machine
Hyper-V Manager.
2. In the results pane, under Virtual Machines, select the virtual machine that you want to
configure.
3. In the Action pane, under the virtual machine name, click Settings.
4. In the navigation pane, click Add Hardware.
5. On the Add Hardware page, choose a network adapter or a legacy network adapter.
Network adapters can only be added to a virtual machine when the machine is turned off.
For more information about each type of adapter, see "Additional considerations" below.
6. Click Add. The Network Adapter or Legacy Network Adapter page appears.
7. Under Network, select the virtual network you want to connect to.
8. If you want to configure a static MAC address or virtual LAN identifier, specify the
address or identifier you want to use.
9. Click OK.
Additional considerations
 By default, membership in the local Administrators group, or equivalent, is

the minimum required to complete this procedure. However, an administrator
can use Authorization Manager to modify the authorization policy so that a
user or group of users can complete this procedure.
 A legacy network adapter works without installing a virtual machine driver

because the driver is already available on most operating systems. The
legacy network adapter emulates a physical network adapter, multiport DEC
21140 10/100TX 100 MB. A legacy network adapter also supports network-
based installations because it includes the ability to boot to the Pre-Boot
Execution Environment (PXE). The legacy network adapter is not supported in
the 64-bit edition of Windows Server 2003 or the Windows XP Professional
x64 Edition.
 After you install Hyper-V and create an external virtual network, your
computer will operate differently. After installation, the parent partition uses
a virtual network adapter to connect to the physical network. When you look
at Network Connections on the parent partition, you will see the original
network adapter and a new virtual network adapter. The original physical
network adapter has nothing bound to it except the Microsoft Virtual Network
Switch Protocol, and the virtual network adapter now has all of the standard
protocols and services bound to it. The virtual network adapter that appears
under Network Connections will have the same name as the virtual
network switch with which it is associated. It is possible to create an internal
virtual network, which will expose a virtual network adapter to the parent
partition without the need to have a physical network adapter associated with
it. Hyper-V only binds the virtual network service to a physical network
adapter when an external virtual network is created. However, networking
will get disrupted for a short period of time on the network adapter when a
virtual network gets created or deleted.

o




 Hyper-V Update List for Windows Server
2008
 Hyper-V Update List for Windows Server
2008 R2
Clustering
Cluster Shared Volumes in Windows Server
2008 R2
 Planning
 Installation
 Configuration
 Migration
 Hyper-V Videos
 Networking
 Remote Desktop Services (Terminal Services)
 Security and Protection
 Storage
 Streaming Media Services
 Web Server (IIS)
 Windows Deployment Services
 Windows Search, Browse, and Organization
o More...
o TechNet Archive
TechNet
TechNet Library
Windows Server
Hyper-V
Getting Started
Comprehensive List of Hyper-V Updat...
Hyper-V Update List for Windows Server 2008
Updated: September 15, 2010
The following table shows the list of software updates and hotfixes for Hyper-V in Windows
Server 2008. Updates that are available on Windows Update are indicated, as well as the
download location for those that are available at the Microsoft Download Center. These updates
and hotfixes can help avoid some known issues and may save you a support call.
Note
Some updates are required only under certain circumstances, as noted in the table. The updates
for Windows Server 2008 Service Pack 2 (SP2) are applied automatically with the service pack,
and do not need to be applied again. Also, you may want to see the list of updates for Hyper-V in
Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkId=183395).
Comprehensive list of Hyper-V updates
Knowl Integrati
edge Requir File Applie on Availa
Name Date Link
Base ed? Name s to Services bility
Article Version
”Hyper-
V
Update
for
Window Windo
Windo
s Server ws
ws6.0- Windo
2008 Update
KB950 6/26/2 KB950 ws 6.0.6001. http://go.microsoft.com/fwli
x64 Yes. ,
050 008 050- Server 18016 nk/?LinkId=139066
Edition” Downl
x64.ms 2008
(This is oad
u
the RTM Center
version
of
Hyper-
V.)
KB950 “A 4/11/2 Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
182 compute 008 you ws6.0- ws Applicab nk/?LinkId=139067
r that is want to KB950 Server le
running
an x86-
based
version
of
start an
Window
x86-
s Server
based
2008 or
virtual
an x86-
machin
based
e
version
running
of
Windo
Window 182-
ws
s Vista x86.ms 2008
Server
may use u
2008 on
fewer
a
processo
comput
rs than
er that
expected
uses a
if the
6-core
number
process
of cores
or.
on a
socket is
not a
power of
2”
“Increas
ed
function
ality and
virtual
machine
control
Windo
in the Yes, for
ws6.0- Windo
Window Failove Not Downl
KB951 9/11/2 KB951 ws http://go.microsoft.com/fwli
s Server r Applicab oad
308 008 308-v2- Server nk/?LinkID=125397
2008 Clusteri le Center
x64.ms 2008
Failover ng.
u
Cluster
Manage
ment
console
for the
Hyper-V
role”
“Hyper- Yes, if
V you are
Windo
Languag using
ws6.0- Windo
e Pack the Not Downl
KB951 6/26/2 KB951 ws http://go.microsoft.com/fwli
Update additio Applicab oad
636 008 636- Server nk/?LinkId=139069
for nal le Center
x86.ms 2008
Window languag
u
s Server es
2008” offered.
“Descrip
tion of
the
Window
s Vista
Service
Pack 1
Manage
ment Yes, to
Tools enable
update remote
for the manage
release ment
version using
of the
Hyper- Hyper-
Windo
V” V Not Downl
KB952 6/26/2 ws http://go.microsoft.com/fwli
(Install Manage Varies Applicab oad
627 008 Server nk/?LinkID=122189
this to r le Center
2008
enable Micros
remote oft
manage Manage
ment of ment
a Consol
compute e
r running (MMC)
Window snap-in.
s
Server 2
008 with
the
Hyper-V
role
installed.
)
KB953 “Error 9/4/20 Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
585 message 08 you are ws6.0- ws Applicab nk/?LinkId=139068
when
you try
to start a
Hyper-V
virtual
machine
on a using a
Window comput
s Server er
2008- running
based or Windo
Window ws
s Vista- Server
based 2008
KB953
compute with
585- Server
r that Non- le
x64.ms 2008
uses the Unifor
u
NUMA m
architect Memor
ure: "An y
error Access
occurred (NUM
while A)
attempti architec
ng to ture.
change
the state
of virtual
machine
VMNA
ME"”
“The
NLB
host
does not
Yes, if
converge
you are Winow
as
using s6.0- Windo
expected Not
KB953 6/25/2 Networ KB953 ws http://go.microsoft.com/fwli
on Applicab Hotfix
828 008 k Load 828- Server nk/?LinkId=139070
Window le
Balanci x64.ms 2008
s Server
ng u
2008
(NLB).
Hyper-V
virtual
machine
s”
“Hyper-
V
Update
for
Window
s Server
2008
x64
Yes, if
Edition”
you are
(Install
using
this to Windo
System
resolve ws6.0- Windo
Center Not Downl
KB956 potential 9/23/2 KB956 ws http://go.microsoft.com/fwli
VMM 2 Applicab oad
589 issues 008 589- Server nk/?LinkId=139611
008 to le Center
when x64.ms 2008
manage
you u
your
manage
environ
Hyper-V
ment.
with
System
Center
Virtual
Machine
Manager
(VMM)
2008.)
KB956 “Update 9/8/20 Yes, if Windo Windo Not Windo http://go.microsoft.com/fwli
697 for 08 the ws6.0- ws Applicab ws nk/?LinkId=139612
Window Volume KB956 Server le Update
s Server Shadow 697- 2008 ,
2008 Copy x64.ms Downl
x64 Service u oad
Edition” (VSS) Center
(Install is
this to utilized
resolve for
an issue backup
in which s.
the
Hyper-V
Volume
Shadow
Copy
Service
(VSS)
does not
back up
virtual
machine
s
properly.
)
“Update
for
Window
s Server
2008
Yes, if
x64
the
Edition”
manage
(Install
ment
this to Windo
operati
enable ws6.0- Windo
ng Downl
KB956 the 9/23/0 KB956 ws 6.0.6001. http://go.microsoft.com/fwli
system oad
710 Hyper-V 8 710-v2- Server 22258 nk/?LinkId=139613
has Center
role to x64.ms 2008
more
support u
than 16
up to 24
logical
logical
process
processo
ors.
rs and
192
virtual
machine
s.)
KB956 “Update 9/23/0 Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
774 for 8 GUIDs ws6.0- ws Applicab nk/?LinkId=139614
Window are KB956 Server le
s Server used 774- 2008
2008 instead x64.ms
x64 of a u
Edition” drive
(Install letter or
this to mount
resolve point.
the
scenario
where a
Backgro
und
Intellige
nt
Transfer
Service
(BITS)
client
cannot
handle
files that
have
paths
that
contain
the
volume
GUID in
Window
s Server
2008.)
“Stop
error
message
on a
Window
s Server
Windo
2008- Windo
ws6.0-
based ws Not
KB957 10/8/2 KB957 http://go.microsoft.com/fwli
compute Yes. Server Applicab Hotfix
967 008 967- nk/?LinkId=139615
r that has 2008 le
x64.ms
the SP2
u
Hyper-V
role
installed:
"STOP
0x00000
01A"”
KB958 “You 11/3/2 Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
065 cannot 008 you are ws6.0- ws Applicab nk/?LinkId=139616
configur using a KB958 Server le
ea non- 065-v2- 2008
Hyper-V Micros x64.ms
virtual oft u
machine clustere
by using d file
Window system
s Server or non-
2008 Micros
Failover oft
Clusterin replicat
g when
the
virtual
machine
uses a
storage
device
that is
managed
by a ion
third- solution
party s.
clustered
file
system
or a
third-
party
replicati
on
solution”
“Virtual
machine
backup
operatio
ns fail in
Window
s Server Yes,
2008 when
when backing
Windo
Hyper-V up a Windo
ws6.0-
virtual volume ws Not
KB958 11/5/2 KB958 http://go.microsoft.com/fwli
machine that is Server Applicab Hotfix
184 008 184- nk/?LinkID=133348
files are mounte 2008 le
x64.ms
saved on d using SP2
u
a volume a
that is volume
mounted GUID.
on a
failover
cluster
by using
a volume
GUID”
KB960 “The 12/17/ Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
578 IRET 2008 you ws6.0- ws Applicab nk/?LinkId=145170
and
IRETD
instructi have a
ons do progra
not m that
support uses the
the IRET
Nested (interru
Task pt KB960
Server
(NT) return) 578-
2008 le
flag in or x64.ms
SP2
protecte IRETD u
d mode (interru
in a pt
Window return
s Server double)
2008 instruct
Hyper-V ion.
environ
ment”
“An
update is
available
for
Window
s Server
2008-
Yes,
based Windo
when Windo
compute ws6.0-
backing ws
KB959 rs to 1/16/2 KB959 6.0.6001. http://go.microsoft.com/fwli
up Server Hotfix
962 address 009 962-v3- 22352 nk/?LinkId=145171
virtual 2008
issues x64.ms
machin SP2
with u
es.
backing
up and
restoring
Hyper-V
virtual
machine
s”
KB963 “The 3/03/2 Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
709 AltGr 009 you are ws6.0- ws Applicab nk/?LinkId=151938
key does using a KB963 Server le
not work German 709- 2008
on a keyboar x64.ms SP2
Linux d. u
virtual
machine
on a
Window
s Server
2008-
based
server
that has
the
Hyper-V
role
enabled”
“You
cannot
connect
to a
Windo
virtual
Windo ws
machine Windo
ws6.0- Update
when the ws Not
KB967 3/24/2 KB967 , http://go.microsoft.com/fwli
Window Yes. Server Applicab
902 009 902- Downl nk/?LinkId=151937
s Server 2008 le
x64.ms oad
2008 SP2
u Center,
Hyper-V
Hotfix
VMMS
certificat
e has
expired”
KB970 “Hyper- 6/23/2 Yes, if Windo Windo Not Downl http://go.microsoft.com/fwli
203 V 009 you are ws6.0- ws Applicab oad nk/?LinkId=178382
Manage using KB970 Vista le Center
ment the 203- SP2
Tools Hyper- x86.ms
update V u
for Manage Windo
Window r ws6.0-
s Vista Micros KB970
Service oft 203-
Pack 2” Manage x64.ms
(Install ment u
this for Consol
fixes for e
the (MMC)
Hyper-V snap-in.
Manage
ment
Tools on
compute
rs that
are
running
Window
s Vista
Service
Pack 2).
“Slow
system
response
together
with
many
other
performa
nce
Windo
issues
ws
occur on Windo
Server
a ws6.0-
2008, Not
KB972 virtualiz 7/14/2 KB972 http://go.microsoft.com/fwli
No. Windo Applicab Hotfix
045 ation 009 045- nk/?LinkId=178381
ws le
server x64.ms
Server
that is u
2008
running
SP2
Window
s Server
2008 and
that has
the
Hyper-V
role
installed
”
KB971 “A 8/5/20 Yes, if Windo Windo Not Hotfix http://go.microsoft.com/fwli
677 Hyper-V 09 you ws6.0- ws Applicab nk/?LinkId=178380
differenc have KB971 Server le
ing disk differen 677- 2008,
that you cing x64.ms Windo
create in disks u ws
Window that Server
s Server were 2008
2008 R2 created SP2
cannot in
be used Windo
ws
Server
2008
R2 and
in
want to
Window
use
s Server
them in
2008”
Windo
ws
Server
2008.
“A
hotfix is
available
that
addresse
s the
issues
that
Yes, if
occur
you are
when Windo
running Windo
you ws6.0-
Hyper- ws
KB975 perform 12/1/2 KB975 6.0.6002. http://go.microsoft.com/fwli
V on Server Hotfix
925 a host- 009 925- 22233 nk/?LinkId=179090
the 2008
level x64.ms
affected SP2
backup u
hardwa
of a
re.
Hyper-V
VM on a
compute
r that is
running
Window
s Server
2008”
KB977 “MS10- 2/9/20 Yes. Windo Windo Not Securit http://go.microsoft.com/fwli
894 010: 10 ws6.0- ws Applicab y nk/?LinkId=193214
Vulnera KB977 Server le bulletin
bility in 894- 2008,
Window x64.ms Windo
s Server u ws
2008 Windo Server
Hyper-V ws6.1- 2008
could KB977 SP2,
allow 894- Windo
denial of x64.ms ws
Server
service” u 2008
R2
“"STOP:
0x00000
01a"
error
message
on a
compute
r that has
an Intel
Yes, if
Westmer
you are
e
running
processo Windo
Hyper-
r ws Not
KB981 4/26/2 V on http://go.microsoft.com/fwli
together n/a Server Applicab Hotfix
791 010 Intel nk/?LinkID=193221
with the 2008 le
Westm
Hyper-V SP2
ere
role
process
installed
ors.
on
Window
s Server
2008 or
on
Window
s Server
2008
R2”
Hyper-V Update List for Windows Server 2008 R2

Updated: September 15, 2010
Applies To: Windows Server 2008 R2
The following table shows the list of software updates and hotfixes for Hyper-V in Windows
Server 2008 R2. Updates that are available on Windows Update are indicated, as well as the
download location for those that are available at the Microsoft Download Center. These updates
and hotfixes can help avoid some known issues and may save you a support call.
Note
Some updates are required only under certain circumstances, as noted in the table. Also, you may
want to see the list of updates for Hyper-V in Windows Server 2008 (which includes updates for
Windows Server 2008 Service Pack 2)(http://go.microsoft.com/fwlink/?LinkId=183322).
Comprehensive list of Hyper-V R2 updates
Integra
Know
tion
ledge App Avail
Requ Service
Base Name Date File Name lies abilit Link
ired? s
Articl to y
Versio
e
n
KB97 “You receive a 10/1/ Yes, Windows6. Win Not Hotfix http://go.microsoft.com/f
4598 "Stop 0x0000007E" 2009 if you 1- dow Applica wlink/?LinkId=181559
error on the first encou KB974598 s ble
restart after you nter -x64.msu Serv
enable Hyper-V on this er
a Windows Server error 2008
2008 R2-based and R2
computer” your
serve
r uses
a “C-
state”
(lowe
r
powe
r
state)
that
is
suppo
rted
by
the
proce
ssor,
but is
not
suppo
rted
by
Hype
r-V.
“The network
connection of a
Win
running Hyper-V
Windows6. dow
virtual machine is
1- s Not
KB97 lost under heavy 10/21 http://go.microsoft.com/f
No. KB974909 Serv Applica Hotfix
4909 outgoing network /2009 wlink/?LinkId=183312
-v2- er ble
traffic on a
x64.msu 2008
Windows Server
R2
2008 R2-based
computer”
Windows6.
Yes, 1-
if you KB975354
are -v2- Win
“A Hyper-V update
runni x64.msu dow
rollup package is
ng a Windows6. s
KB97 available for a 11/10 6.1.760 http://go.microsoft.com/f
backu 1- Serv Hotfix
5354 computer that is /2009 0.20542 wlink/?LinkId=179092
p or KB975354 er
running Windows
restor -ia64.msu 2008
Server 2008 R2”
e Windows6. R2
soluti 1-
on. KB975354
-x86.msu
Yes,
“Stop error message
if you
on an Intel Xeon
are
5500 series
runni Win
processor-based
ng Windows6. dow Down
computer that is
Hype 1- s Not load
KB97 running Windows 11/20 http://go.microsoft.com/f
r-V KB975530 Serv Applica Cente
5530 Server 2008 R2 and /2009 wlink/?LinkId=179091
on -v3- er ble r,
that has the Hyper-
the x64.msu 2008 Hotfix
V role installed:
affect R2
"0x00000101 -
ed
CLOCK_WATCH
hard
DOG_TIMEOUT"
ware.
KB97 “Virtual machines 10/14 No. Windows6. Win Not Hotfix http://go.microsoft.com/f
4672 stop responding /2009 1- dow Applica wlink/?LinkId=193212
(hang) during KB974672 s ble
startup and the -x64.msu Serv
Vmms.exe process er
crashes on a 2008
Windows Server R2
2008 R2 computer
that has the Hyper-
V role installed“
Win
dow
s
Serv
er
2008
,
Windows6.
Win
“MS10-010: 0-
dow
Vulnerability in KB977894 Securi
s Not
KB97 Windows Server 2/9/2 -x64.msu ty http://go.microsoft.com/f
Yes. Serv Applica
7894 2008 Hyper-V 010 Windows6. bulleti wlink/?LinkId=193214
er ble
could allow denial 1- n
2008
of service” KB977894
SP2,
-x64.msu
Win
dow
s
Serv
er
2008
R2
Yes,
Win
“Stop error in if you
dow
Windows Server store Windows6.
s Not
KB98 2008 R2: 3/12/ VHD 1- http://go.microsoft.com/f
Serv Applica Hotfix
0856 "0x000000CA 2010 s on KB980856 wlink/?LinkId=193215
er ble
PNP_DETECTED_ non- -x64.msu
2008
FATAL_ERROR"” PNP
R2
disks.
Yes,
if you
“The computer
are Win
stops responding or
runni dow
restarts during the Windows6.
ng s Not
KB98 Hyper-V Live 3/27/ 1- http://go.microsoft.com/f
Hype Serv Applica Hotfix
1618 Migration process 2010 KB981618 wlink/?LinkID=193217
r-V er ble
in Windows Server -x64.msu
on 2008
2008 R2” (relates to
AMD R2
AMD Errata 383)
proce
ssors.
KB98 “Network 4/28/ Yes, Windows6. Win 6.1.760 Hotfix http://go.microsoft.com/f
1836 connectivity for a 2010 if the 1- dow 0.20683 wlink/?LinkId=193220
Windows Server serve KB981836 s
2003-based Hyper- r - Serv
runni
ng
Hype
r-V
has a
virtua
l
x86.msuW
V virtual machine is mach
indows6.1- er
lost temporarily in ine
KB981836 2008
Windows Server that
-v2- R2
2008 R2” is
x64.msu
runni
ng
Wind
ows
Serve
r
2003.
Yes,
“"STOP:
if you
0x0000001a" error
are
message on a
runni Win
computer that has
ng dow
an Intel Westmere Windows6.
Hype s Not
KB98 processor together 5/5/2 1- http://go.microsoft.com/f
r-V Serv Applica Hotfix
1791 with the Hyper-V 010 KB981791 wlink/?LinkID=193221
on er ble
role installed on -x64.msu
Intel 2008
Windows Server
West R2
2008 or on
mere
Windows Server
proce
2008 R2”
ssors.
KB22 “The network Augu Yes, Varies Win 6.1.760 Hotfix http://go.microsoft.com/f
23005 connection is lost st 12, if the dow 0.20778 wlink/?LinkId=2019
for a Windows 2010 serve s
Server 2003-based r Serv
or Windows XP- runni er
based virtual ng 2008
machine that is Hype R2
hosted on a r-V
computer that is has a
running Windows virtua
Server 2008 R2” l
mach
ine
that
is
runni
ng
Wind
ows
Serve
r
2003
or
Wind
ows
XP.

o




Clustering
Cluster Shared Volumes in Windows
Server 2008 R2
 Planning
 Installation
 Configuration
 Migration
 Hyper-V Videos
 Networking
 Remote Desktop Services (Terminal Services)
 Security and Protection
 Storage
 Streaming Media Services
 Web Server (IIS)
 Windows Deployment Services
 Windows Search, Browse, and Organization
o More...
o TechNet Archive
TechNet
TechNet Library
Windows Server
Hyper-V
Getting Started
Hyper-V: Using Hyper-V and Failover Clustering

Updated: June 9, 2010
Applies To: Windows Server 2008, Windows Server 2008 R2
This guide walks you through the steps required to set up Hyper-V™ and the Failover Clustering
feature to use these two technologies together.
Scenario overview
The Hyper-V role enables you to create a virtualized server computing environment using a
technology that is part of the Windows Server® 2008 R2 operating system. This solution is
provided through Hyper-V. You can use a virtualized computing environment to improve the
efficiency of your computing resources and improve server availability without using as many
physical computers as you would need in a failover configuration that uses only physical
computers.
The Failover Clustering feature enables you to create and manage failover clusters. A failover
cluster is a group of independent computers that work together to increase the availability of
applications and services. The clustered servers (called nodes) are connected by physical cables
and by software. If one of the cluster nodes fails, another node begins to provide service (a
process known as failover). Users experience a minimum of disruptions in service.
This guide shows you how to use these two technologies together to make a virtual machine
highly available. You will do this by creating a simple two-node cluster and a virtual machine,
and then verify the set-up by failing over the virtual machine from one node to the other.
Requirements for using Hyper-V and Failover Clustering
To use the Hyper-V role on a failover cluster with two nodes, you need the hardware, software,
accounts, and network infrastructure described in the sections that follow.
In Windows Server 2008 R2, a new failover clustering feature called Cluster Shared Volumes
was introduced. With CSV, the configuration of clustered virtual machines is much simpler than
before. For information about requirements for using Hyper-V with Cluster Shared Volumes, see
Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2.
Hardware requirements for Hyper-V
Hyper-V requires an x64-based processor, hardware-assisted virtualization, and hardware-

enforced Data Execution Prevention (DEP). Specifically, you must enable the Intel XD bit
(execute disable bit) or AMD NX bit (no execute bit).You can identify systems that support the
x64 architecture and Hyper-V by searching the Windows Server catalog for Hyper-V as an
additional qualification. The Windows Server catalog is available at the Microsoft Web site
http://go.microsoft.com/fwlink/?LinkId=111228.
Hardware requirements for a two-node failover cluster
You will need the following hardware for a two-node failover cluster:
 Servers: We recommend that you use a set of matching computers that

contain either the same or similar features.
Important
Microsoft supports a failover cluster solution only if all the hardware features
are marked as "Certified for Windows Server 2008 R2." In addition, the
complete configuration (servers, network, and storage) must pass all tests in
the Validate a Configuration Wizard, which is included in the Failover Cluster
Manager snap-in.
For information about hardware compatibility for Windows Server 2008 R2,
see http://go.microsoft.com/fwlink/?LinkId=139145.
 Network adapters and cable (for network communication): The

network hardware, like other features in the failover cluster solution, must be
marked as “Certified for Windows Server 2008 R2.” If you use iSCSI, your
network adapters should be dedicated to either network communication or
iSCSI, not both.
In the network infrastructure that connects your cluster nodes, avoid having
single points of failure. There are multiple ways of accomplishing this. You
can connect your cluster nodes by multiple, distinct networks. Alternatively,
you can connect your cluster nodes with one network that is constructed with
teamed network adapters, redundant switches, redundant routers, or similar
hardware that removes single points of failure.
Note
If you connect cluster nodes with a single network, the network will pass the
redundancy requirement in the Validate a Configuration Wizard. However, the
report from the wizard will include a warning that the network should not have
single points of failure.
 For more details about the network configuration required for a failover
cluster, see Network infrastructure and domain account requirements for a
two-node failover cluster, later in this guide.
 Device controllers or appropriate adapters for the storage:
o For Serial Attached SCSI or Fibre Channel: If you are using Serial
Attached SCSI or Fibre Channel, in all clustered servers, the mass-
storage device controllers that are dedicated to the cluster storage
should be identical. They should also use the same firmware version.
Note
With Windows Server 2008 R2, you cannot use parallel SCSI to connect
the storage to the clustered servers. This was also true for Windows
Server 2008.
o For iSCSI: If you are using iSCSI, each clustered server must have one
or more network adapters or host bus adapters that are dedicated to
the cluster storage. The network that you use for iSCSI cannot be used
for network communication. In all clustered servers, the network
adapters that you use to connect to the iSCSI storage target should be
identical, and we recommend that you use Gigabit Ethernet or a faster
network adapter.
Note
You cannot use teamed network adapters, because they are not
supported with iSCSI.
o For more information about iSCSI, see the iSCSI FAQ on the Microsoft
Web site (http://go.microsoft.com/fwlink/?LinkId=61375).
 Storage: You must use shared storage that is compatible with Windows
Server 2008 R2.
A feature of failover clusters called Cluster Shared Volumes is specifically

designed to enhance the availability and manageability of virtual machines.
Cluster Shared Volumes are volumes in a failover cluster that multiple nodes
can read from and write to at the same time. This feature enables multiple
nodes to concurrently access a single shared volume. The Cluster Shared
Volumes feature is only supported for use with Hyper-V and other
technologies specified by Microsoft.
On a failover cluster that uses Cluster Shared Volumes, multiple clustered

virtual machines that are distributed across multiple cluster nodes can all
access their Virtual Hard Disk (VHD) files at the same time, even if the VHD
files are on a single disk (LUN) in the storage. This means that the clustered
virtual machines can fail over independently of one another, even if they use
only a single LUN. When Cluster Shared Volumes is not enabled, a single disk
(LUN) can only be accessed by a single node at a time. This means that
clustered virtual machines can only fail over independently if each virtual
machine has its own LUN, which makes the management of LUNs and
clustered virtual machines more difficult.
For a two-node failover cluster, the storage should contain at least two
separate volumes (LUNs), configured at the hardware level. Do not expose
the clustered volumes to servers that are not in the cluster. One volume will
function as the witness disk (described later in this section). One volume will
contain the files that are being shared between the cluster nodes. This
volume serves as the shared storage on which you will create the virtual
machine and the virtual hard disk. To complete the steps as described in this
document, you only need to expose one volume.
Storage requirements include the following:
o To use the native disk support included in failover clustering, use basic
disks, not dynamic disks.
o We recommend that you format the partitions with NTFS (for the
witness disk, the partition must be NTFS). If you have a disk witness or
use Cluster Shared Volumes, the partition for each of those must be
NTFS.
For Cluster Shared Volumes, there are no special requirements other

than the requirement for NTFS.
o For the partition style of the disk, you can use either master boot
record (MBR) or GUID partition table (GPT).
A disk witness is a disk in the cluster storage that is designated to hold a

copy of the cluster configuration database. A failover cluster has a disk
witness only if this is specified as part of the quorum configuration. For this
two-node cluster, the quorum configuration will be Node and Disk Majority,
the default for a cluster with an even number of nodes. Node and Disk
Majority means that the nodes and the witness disk each contain copies of
the cluster configuration, and the cluster has quorum as long as a majority
(two out of three) of these copies are available.
Deploying storage area networks with failover clusters
When deploying a storage area network (SAN) with a failover cluster, follow these guidelines:
 Confirm compatibility of the storage: Confirm with manufacturers and

vendors that the storage, including drivers, firmware, and software used for
the storage, are compatible with failover clusters in Windows Server 2008 R2.
Important
Storage that was compatible with server clusters in Windows Server 2003
might not be compatible with failover clusters in Windows Server 2008 R2.
Contact your vendor to ensure that your storage is compatible with failover
clusters in Windows Server 2008 R2.
 Failover clusters include the following new requirements for storage:
o Improvements in failover clusters (as compared to server clusters in

Windows Server 2003) require that the storage respond correctly to
specific SCSI commands. To confirm that your storage is compatible,
run the Validate a Configuration Wizard. In addition, you can contact
the storage vendor.
o The miniport driver used for the storage must work with the Microsoft
Storport storage driver.
 Isolate storage devices, one cluster per device: Servers from different
clusters must not be able to access the same storage devices. In most cases,
a LUN that is used for one set of cluster servers should be isolated from all
other servers through LUN masking or zoning.
 Consider using multipath I/O software: In a highly available storage

fabric, you can deploy failover clusters with multiple host bus adapters by
using multipath I/O software. This provides the highest level of redundancy
and availability. For Windows Server 2008 R2, your multipath solution must
be based on Microsoft Multipath I/O (MPIO). Your hardware vendor will usually
supply an MPIO device-specific module (DSM) for your hardware, although
Windows Server 2008 R2 includes one or more DSMs as part of the operating
system.
Important
Host bus adapters and multipath I/O software can be very version sensitive. If
you are implementing a multipath solution for your cluster, you should work
closely with your hardware vendor to choose the correct adapters, firmware,
and software for Windows Server 2008 R2.
Software requirements for using Hyper-V and Failover Clustering

The following are the software requirements for using Hyper-V and the Failover Clustering
feature:
 All the servers in a failover cluster must either run the x64-based version or
the Itanium architecture-based version of Windows Server 2008 R2 (nodes
within a single failover cluster cannot run different versions).
 All the servers should have the same software updates (patches) and service
packs.
 Windows Server 2008 R2 Enterprise or Windows Server 2008 R2 Datacenter

must be used for the physical computers. These servers must run the same
version of Windows Server 2008 R2, including the same type of installation.
That is, both servers must be either a full installation or a Server Core
installation.
 If you do not want to install Windows Server 2008 R2 Enterprise or Windows

Server 2008 R2 Datacenter on the test virtual machine, you will need the
installation media for the operating system. The instructions in this guide
assume that you will install Windows Server 2008 R2 on the virtual machine.
Network infrastructure and domain account requirements for a two-node

failover cluster
You will need the following network infrastructure for a two-node failover cluster and an
administrative account with the following domain permissions:
 Network settings and IP addresses: When you use identical network

adapters for a network, also use identical communication settings on those
adapters (for example, Speed, Duplex Mode, Flow Control, and Media Type).
Also, compare the settings between the network adapter and the switch it
connects to and make sure that no settings are in conflict.
If you have private networks that are not routed to the rest of your network
infrastructure, ensure that each of these private networks uses a unique
subnet. This is necessary even if you give each network adapter a unique IP
address. For example, if you have a cluster node in a central office that uses
one physical network, and another node in a branch office that uses a
separate physical network, do not specify 10.0.0.0/24 for both networks, even
if you give each adapter a unique IP address.
For more information about the network adapters, see Hardware

requirements for a two-node failover cluster, earlier in this guide.
 DNS: The servers in the cluster must be using Domain Name System (DNS)
for name resolution. The DNS dynamic update protocol can be used.
 Domain role: All servers in the cluster must be in the same Active Directory
domain. As a best practice, all clustered servers should have the same
domain role (either member server or domain controller). The recommended
role is member server.
 Domain controller: We recommend that your clustered servers be member

servers. If they are, you need an additional server that acts as the domain
controller in the domain that contains your failover cluster.
 Clients: As needed, you can connect one or more networked clients to the
failover cluster that you create, and observe the effect on a client when you
move or fail over the highly available virtual machine from one cluster node
to the other.
 Account for administering the cluster: When you first create a cluster or
add servers to it, you must be logged on to the domain with an account that
has administrator rights and permissions on all servers in that cluster. The
account does not need to be a Domain Admins account, but can be a Domain
Users account that is in the Administrators group on each clustered server.
In addition, if the account is not a Domain Admins account, the account (or
the group that the account is a member of) must be given the Create
Computer Objects and Read All Properties permissions in the domain.
Note
There is a change in the way the Cluster service runs in Windows

Server 2008 R2, as compared to Windows Server 2003. In Windows
Server 2008 R2, there is no Cluster service account. Instead, the Cluster
service automatically runs in a special context that provides the specific
permissions and privileges that are necessary for the service (similar to the
local system context, but with reduced privileges).
Limitations for using Hyper-V and Failover Clustering
Specific limitations for using Hyper-V and the failover clustering feature are outlined below:
 A maximum number of 16 nodes in the failover cluster are allowed.
 You can have a maximum number of 1000 virtual machines per cluster for
server computer virtualization, with a maximum of 384 on any one node.
When Hyper-V is used in conjunction with Virtual Desktop Infrastructure (VDI)
for client computer virtualization, you can have a maximum of 1000 VDI
(Windows XP/Windows Vista®/Windows® 7) virtual machines per cluster,
with a maximum of 384 on any one node.
 The number of virtual machines allowed for each node does not change
regardless of the size of the cluster.
Steps for using Hyper-V and Failover Clustering

 Step 1: Connect both physical computers to the networks and storage
 Step 2: Install Hyper-V and Failover Clustering on both physical computers
 Step 3: Create a virtual network
 Step 4: Validate the cluster configuration
 Step 5: Create the cluster
 Step 6: Create a virtual machine and reconfigure the automatic start action
 Step 7: Make the virtual machine highly available
 Step 8: Configure the virtual machine
 Step 9: Test a planned failover
 Step 10: Test an unplanned failover
 Step 11: Modify the settings of a virtual machine
 Step 12: Remove a virtual machine from a cluster
Step 1: Connect both physical computers to the networks and storage
Use the following instructions to connect your selected cluster servers to networks and storage.
To connect the cluster servers to the networks and storage
1. For details about the kinds of network adapters and device controllers that you can use
with Windows Server 2008 R2, review the details about networks in Hardware
Requirements for a Two-Node Failover Cluster and Network infrastructure and domain
account requirements for a two-node failover cluster, earlier in this guide.
2. Connect and configure the networks that the servers in the cluster will use.
Note
If you want to include clients or a non-clustered domain controller as part of

your test configuration, make sure that these computers can connect to the
clustered servers through at least one network.
3. Follow the manufacturer's instructions for physically connecting the servers to the
storage.
4. Ensure that the disks (LUNs) that you want to use in the cluster are exposed to the servers
that you will cluster (and only those servers). You can use any of the following interfaces
to expose disks or LUNs:
o The interface provided by the manufacturer of the storage.
o An appropriate iSCSI interface.

o Microsoft Storage Manager for SANs (part of the operating system in
Windows Server 2008 R2). To use this interface, you need to contact
the manufacturer of your storage for a Virtual Disk Service (VDS)
provider package that is designed for your storage.
5. If you have purchased software that controls the format or function of the disk, follow the
instructions from the vendor about how to use that software with Windows
Server 2008 R2.
6. On one of the servers that you want to cluster, click Start, click Administrative Tools,
click Computer Management, and then click Disk Management. (If the User Account
Control dialog box appears, confirm that the action it displays is what you want, and
then click Continue.) In Disk Management, confirm that the cluster disks are visible.
7. If you want to have a storage volume larger than 2 terabytes, and you are using the
Windows interface to control the format of the disk, convert that disk to the partition style
called GUID partition table (GPT). To do this, back up any data on the disk, delete all
volumes on the disk and then, in Disk Management, right-click the disk (not a partition)
and click Convert to GPT Disk. For volumes smaller than 2 terabytes, instead of using
GPT, you can use the partition style called master boot record (MBR).
Important
o You can use either the MBR or the GPT partition style for a disk
that is used by a failover cluster, but you cannot use a disk that you
have converted to dynamic by using Disk Management.
o If you have purchased software that controls the format or

function of the disk, contact the vendor for instructions about how to
use that software with Windows Server 2008 R2.
8. Check the format of any exposed volume or LUN. We recommend NTFS for the format
(for the witness disk, you must use NTFS).
Step 2: Install Hyper-V and Failover Clustering on both physical computers
In this step, you install the Hyper-V role and the Failover Clustering feature.
Procedure 1: Install the Hyper-V role
In this procedure, you install the Hyper-V role on both servers. You can install Hyper-V on
either a full installation or a Server Core installation. You can use Server Manager to install
Hyper-V on a full installation, as described in the following procedure. To install Hyper-V on a
Server Core installation, you must perform the installation from a command prompt. Run the
following command:
Start /w ocsetup Microsoft-Hyper-V
When installing Hyper-V on a Server Core installation, you can manage the Hyper-V installation
in the following ways:
 Locally and remotely using Windows PowerShell. By using Windows
PowerShell locally on a computer running a Server Core installation of
Windows Server 2008 R2 or remotely from a computer running Windows
Server 2008 R2, you can connect to a server running a Server Core
installation in the same way that you would connect to any computer running
Windows.
 Locally and remotely using a command prompt. By using the Windows

command-line tools at a command prompt, you can manage servers running
a Server Core installation.
 Remotely using an MMC snap-in. By using an MMC snap-in from a

computer running Windows Vista, Windows 7, Windows Server 2008, or
Windows Server 2008 R2 you can connect to a server running Server Core
installation in the same way that you would connect to any computer running
Windows.
 Remotely using Remote Server Administration Tools (RSAT). You can

install RSAT on either Windows Vista or a full installation of Windows
Server 2008 R2 and use these tools to administer Server Core. The
advantage of using RSAT is that it gives you the full complement of MMC
consoles; by comparison, on a full installation of Windows Server 2008 R2,
you may be missing some consoles because of certain roles and features not
being installed on your server. Using MMC snap-ins or RSAT allows you to
administer a Server Core installation the same way that you administer a full
installation—without the need of learning the syntax of many command-line
utilities.
To install Hyper-V on a full installation of Windows Server 2008 R2
1. Click Start, and then click Server Manager.

2. In the Roles Summary area of the Server Manager main window, click Add Roles.
3. On the Select Server Roles page, click Hyper-V.
4. On the Create Virtual Networks page, if the network adapters are identical on both
physical computers, select a physical adapter to create a virtual network that provides
access to the physical network. If the network adapters are not identical, do not create a
virtual network at this time. You can create the virtual network later by following the
instructions in Step 4, Create a virtual network.
5. On the Confirm Installation Selections page, click Install.
6. The computer must be restarted to complete the installation. Click Close to finish the
wizard, and then click Yes to restart the computer.
7. After you restart the computer, log on with the same account you used to install the role.
After the Resume Configuration Wizard completes the installation, click Close to finish
the wizard.
Procedure 2: Install the failover cluster feature
In this step, you install the failover cluster feature on both servers. The servers must be running
Windows Server 2008 R2.
To install the failover cluster feature on a Server Core installation, run the following command:
Start /w ocsetup FailoverCluster-Core
To install the failover cluster feature on a full installation of Windows

Server 2008 R2
1. If you recently installed Windows Server 2008 R2, the Initial Configuration Tasks
interface is displayed. Under Customize This Server, click Add features. Then skip to
step 3.
2. If the Initial Configuration Tasks interface is not displayed and Server Manager is not
running, click Start, click Administrative Tools, and then click Server Manager. (If the
User Account Control dialog box appears, confirm that the action it displays is what you
want, and then click Continue.)
In Server Manager, under Features Summary, click Add Features.
3. In the Add Features Wizard, click Failover Clustering, and then click Install.
4. Follow the instructions in the wizard to complete the installation of the feature. When the
wizard finishes, close it.
5. Repeat the process for each server that you want to include in the cluster.
Step 3: Create a virtual network
You will need to perform this step on both physical computers if you did not create the virtual
network when you installed the Hyper-V role. This virtual network provides the highly available
virtual machine with access to the physical network.
To create a virtual network
1. Open Hyper-V Manager.

2. From the Actions menu, click Virtual Network Manager.
3. Under Create virtual network, select External.
4. Click Add. The New Virtual Network page appears.
5. Type a name for the new network. Make sure you use exactly the same name on both
servers running Hyper-V.
6. Under Connection Type, click External and then select the physical network adapter.
7. Click OK to save the virtual network and close Virtual Network Manager.
Step 4: Validate the cluster configuration

Before you create the cluster, we strongly recommend that you run a full validation test of your
configuration. Validation helps you to confirm that the configuration of your servers, network,
and storage meets a set of specific requirements for failover clusters. You can validate either an
existing cluster or one or more servers that are not yet clustered.
To validate the failover cluster configuration
1. To open the failover cluster snap-in, click Start, click Administrative Tools, and then
click Failover Cluster Management. (If the User Account Control dialog box appears,
confirm that the action it displays is what you want, and then click Continue.)
2. In the Failover Cluster Manager snap-in, confirm that Failover Cluster Manager is
selected and then, in the center pane under Management, click Validate a
Configuration.
3. Follow the instructions in the wizard to specify the servers. Run all tests to fully validate
the cluster before creating a cluster.
The Summary page appears after the tests run.
4. While still on the Summary page, click View Report and read the test results. To view
Help topics that will help you interpret the results, click More about cluster validation
tests.
To view the results of the tests after you close the wizard, see
SystemRoot\Cluster\Reports\Validation Report date and time.html where SystemRoot is
the folder in which the operating system is installed (for example, C:\Windows).
5. As necessary, make changes to the configuration and rerun the tests.
Step 5: Create the cluster
To create a cluster, you run the Create Cluster wizard.
To run the Create Cluster wizard
1. To open the failover cluster snap-in, click Start, click Administrative Tools, and then
click Failover Cluster Management. (If the User Account Control dialog box appears,
confirm that the action it displays is what you want, and then click Continue.)
2. Confirm that Failover Cluster Manager is selected and then, in the center pane under
Management, click Create a cluster.
Follow the instructions in the wizard to specify:
o The servers to include in the cluster.
o The name of the cluster.

o Any IP address information that is not automatically supplied by your
Dynamic Host Configuration Protocol (DHCP) settings.
3. After the wizard runs and the Summary page appears, to view a report of the tasks the
wizard performed, click View Report.
To view the report after you close the wizard, see SystemRoot\Cluster\Reports\ where
SystemRoot is the folder in which the operating system is installed (for example,
C:\Windows).
Step 6: Create a virtual machine and reconfigure the automatic start action
In this step, you create a virtual machine and reconfigure the automatic action that controls the
virtual machine's behavior when the Hyper-V Virtual Machine Management service starts.
Procedure 1: Create a virtual machine
In this step, you use the New Virtual Machine Wizard to create a virtual machine.
On a Server Core installation, you have the option to create a virtual machine using the failover
clustering PowerShell cmdlet, Add-ClusterVirtualMachineRole. The following is an example
of how to use this cmdlet to create a virtual machine:
Add-ClusterVirtualMachineRole -VirtualMachine VM1 -Name "MainServer1"
This command configures VM1 as a clustered virtual machine, and assigns the name
MainServer1 to the virtual machine.
Important
You must choose the shared storage as the location to store the virtual machine and the virtual
hard disk. Otherwise, you will not be able to make the virtual machine highly available. To make
the shared storage available to the virtual machine, you must create the virtual machine on the
physical computer that is the node which owns the storage.
To create a virtual machine
Hyper-V Manager.
2. If you are not already connected to the server that owns the shared storage, connect to
that server.
3. From the Action pane, click New, and then click Virtual Machine.
4. From the New Virtual Machine Wizard, click Next.
5. On the Specify Name and Location page, specify a name for the virtual machine, such
as FailoverTest. Click Store the virtual machine in a different location, and then type
the full path or click Browse and navigate to the shared storage.
6. On the Memory page, specify the amount of memory required for the operating system
that will run on this virtual machine. For example, specify 1024 MB to run Windows
Server 2008 R2.
7. On the Networking page, connect the network adapter to the virtual network that is
associated with the physical network adapter.
8. On the Connect Virtual Hard Disk page, click Create a virtual hard disk. If you want
to change the name, type new a name for the virtual hard disk. Click Next.
9. On the Installation Options page, click Install an operating system from a boot
CD/DVD-ROM. Under Media, specify the location of the media, and then click Finish.
Important
Do not start the virtual machine at this point. The virtual machine must be
turned off so that you can make it highly available.
Procedure 2: Reconfigure automatic start action for the virtual machine
Automatic actions let you automatically manage the state of the virtual machine when the Hyper-
V Virtual Machine Management service starts or stops. However, when you make a virtual
machine highly available, the management of virtual machine state should be controlled through
the Cluster service. In this step, you reconfigure the automatic start action for the virtual
machine.
Important
Do not to intentionally shut down a node while a virtual machine is running on the
node. If you need to shut down the node, take the virtual machine offline, and then
shut down the node. Step 11: Modify the settings of a virtual machine shows you
how to take a virtual machine offline.
To reconfigure automatic start action for the virtual machine
1. In Hyper-V Manager, under Virtual Machines, select FailoverTest, the virtual machine
that you created in Step 6, and then in the Action pane, under the virtual machine name,
click Settings.
2. In the left pane, click Automatic Start Action.
3. Under What do you want this virtual machine to do when the physical computer
starts?, click Nothing and then click Apply.
Step 7: Make the virtual machine highly available
To make the virtual machine highly available, you run the High Availability Wizard.
Note
The virtual machine must be turned off so that you can make it
highly available.
To make a virtual machine highly available
1. In the Failover Cluster Manager snap-in, if the cluster that you want to configure is not
displayed, in the console tree, right-click Failover Cluster Manager, click Manage a
Cluster, and then select or specify the cluster that you want.
2. If the console tree is collapsed, expand the tree under the cluster that you want to
configure.
3. Click Services and Applications.
4. In the Action pane, click Configure a Service or Application.
5. If the Before You Begin page of the High Availability Wizard appears, click Next.
6. On the Select Service or Application page, click Virtual Machine and then click Next.
7. On the Select Virtual Machine page, check the name of the virtual machine that you
want to make highly available, and then click Next.
8. Confirm your selection and then click Next again.
9. The wizard configures the virtual machine for high availability and provides a summary.
To view the details of the configuration, click View Report. To close the wizard, click
Finish.
10. To verify that the virtual machine is now highly available, you can check in either one of
two places in the console tree:
1. Expand Services and Applications. The virtual machine should be
listed under Services and Applications.
2. Expand Nodes. Select the node on which you created the virtual
machine. The virtual machine should be listed under Services and
Applications in the Results pane (the center pane).
11. To bring the virtual machine online, under Services and Applications, right-click the
virtual machine and then click Bring this service or application online. This action will
bring the virtual machine online and start it.
Step 8: Install the guest operating system on the virtual machine
In this step, you install Windows Server 2008 on the virtual machine that you created in step 5.
Then, you install the integration services, which improve performance and integration with the
physical computer.
Note
If you are installing a different operating system, integration services may not be
available. For more information, see About Virtual Machines and Guest Operating
Systems (http://go.microsoft.com/fwlink/?LinkId=128037).
To install the guest operating system on the virtual machine
Hyper-V Manager.
2. Connect to the virtual machine. From the Virtual Machines section of the results pane,
using one of the following methods:
o Right-click the name of the virtual machine, and then click Connect.
o Select the name of the virtual machine. In the Action pane, click
Connect.
3. The Virtual Machine Connection tool opens.

4. From the Action menu in the Virtual Machine Connection window, click Start.
5. The virtual machine starts, searches the startup devices, and loads the installation
package.
6. Proceed through the installation.
Note
Depending on the operating system being installed, the mouse pointer may change to a
small dot when you move the mouse cursor over the image of the setup window. If this
occurs, click anywhere in the virtual machine window. This action "captures" the mouse
so that keyboard and mouse input is sent to the virtual machine. To return the mouse
input to the physical computer, press Ctrl+Alt+Left arrow and then move the mouse
pointer outside of the virtual machine window.
7. Hyper-V includes a software package for supported guest operating systems that
improves integration between the physical computer and the virtual machine. This
package is referred to as integration services. Newer versions of supported Windows
operating systems include the integration services and do not require installation after you
install the guest operating system. For more information about which operating systems
are supported and which of those require you to install integration services, see the
deployment content for Hyper-V at the Windows Server 2008 Technical Library
(http://go.microsoft.com/fwlink/?LinkID=128037).
Step 9: Test a planned failover
To test a planned failover, you use Failover Cluster Manager to move FailoverTest, the virtual
machine that you created in Step 6, to another node.
To test a planned failover
1. In the Failover Cluster Manager snap-in, if the cluster that you want to manage is not
configure.
3. Expand Services and Applications, and then click FailoverTest, the virtual machine that
you created in Step 6.
4. Under Actions (on the right), click Move this service or application to another node,
and click the name of the other node.
As the FailoverTest virtual machine is moved, the status is displayed in the results pane
(center pane). Optionally, you can repeat this step to move the FailoverTest virtual
machine to an additional node or back to the original node.
5. You can verify that the move succeeded by inspecting the details of each node.
Step 10: Test an unplanned failover
To test an unplanned failover, you stop the Cluster service.
To test an unplanned failover
1. In the Failover Cluster Manager snap-in, if the cluster you want to manage is not
2. If the console tree is collapsed, expand the tree under the cluster you want to manage.
3. To minimize disruption to clients, before stopping the Cluster service on a node, move
the applications that are currently owned by that node to another node. To do this, expand
the console tree under the cluster that you want to manage, and then expand Services and
Applications. Click each service or application and (in the center pane) view the
Current Owner. If the owner is the node on which you want to stop the Cluster service,
right-click the service or application, click Move this service or application to another
node, and then choose the node
4. Expand the console tree under Nodes.
5. Right-click the node that runs the virtual machine, and then click More Actions.
6. Click Stop Cluster Service.
7. The virtual machine will be moved to the other node.
Step 11: Modify the settings of a virtual machine
If you change the configuration of a virtual machine, we recommend that you use the Failover
Cluster Manager snap-in to access the virtual machine settings. When you do this, the cluster is
updated automatically with the configuration changes. However, if you make changes to the
virtual machine settings from the Hyper-V Manager snap-in, you must update the cluster
manually after you make the changes. If the configuration is not refreshed after networking or
storage changes are made, a subsequent failover may not succeed or may succeed but result in
the virtual machine being configured incorrectly.
To modify the settings of a virtual machine
configure.
3. Expand Services and Applications, and then click FailoverTest, the virtual machine that
you created in Step 6, to modify the settings for this virtual machine.
4. In the center pane, right-click the virtual machine resource, and then click Settings. (If
you do not see Settings in the menu, collapse the virtual machine resource and then right-
click it.)
The Settings interface appears. This is the same interface that you see in Hyper-V
Manager.
5. Configure the settings for the virtual machine.
Note
If you use Hyper-V Manager instead of Failover Cluster Manager to configure settings
for a virtual machine, be sure to refresh the configuration of the virtual machine in
Failover Cluster Manager. To do this, expand Services and Applications, and then
click the virtual machine for which you want to refresh the configuration. In the
Actions pane, scroll down, click More Actions, and then click Refresh virtual
machine configuration.
Step 12: Remove a virtual machine from a cluster
When you want to remove a virtual machine from a cluster, the procedure you need to use varies
depending on whether you want to keep the virtual machine. This step illustrates both scenarios.
Scenario A: To remove a virtual machine from a cluster and retain the

virtual machine
1. Use the Failover Cluster Manager snap-in to take the virtual machine offline. Under
Services and Applications, select FailoverTest, the virtual machine that you created in
Step 6. In the results pane, right-click Failover and then click Take this resource
offline.
2. This is an optional step that shows you how to export the virtual machine. Exporting a
virtual machine allows you to move the virtual machine to another server running Hyper-
V, such as a non-clustered server. Switch to Hyper-V Manager and verify that the
FailoverTest virtual machine is selected. Under Actions, click Export. Type or browse
to specify a location in which to export the virtual machine, and then click Export.
Important
If you plan to import the virtual machine to another cluster, use either Hyper-
V Manager or Microsoft System Center Virtual Machine Manager (VMM). If you
import a virtual machine using Hyper-V Manager, afterwards, follow the
procedure in Step 7: Make the virtual machine highly available.
3. In Hyper-V Manager, verify that the FailoverTest virtual machine is selected. Under
Actions, click Delete.
4. Switch to the Failover Cluster Manager snap-in. Expand Services and Applications, and
then select the FailoverTest virtual machine. Right-click FailoverTest and then click
Delete. This action removes the virtual machine from the cluster.
Important
The following steps show you how to delete a virtual machine and its files. Perform
these steps only if you do not want to keep the virtual machine.
Scenario B: To remove a virtual machine from a cluster and delete the

virtual machine
1. Use the Failover Cluster Manager snap-in to take the virtual machine offline. Under
Services and Applications, select the FailoverTest virtual machine. In the results pane,
right-click Failover and then click Take this resource offline.
2. Switch to Hyper-V Manager and select the FailoverTest virtual machine. Under Actions,
click Delete.
3. Switch to the Failover Cluster Manager snap-in. Expand Services and Applications, and
then select the FailoverTest virtual machine. Right-click FailoverTest and then click
Delete. This action removes the virtual machine from the cluster.
4. Manually delete the virtual machine, and virtual hard disk from the shared storage.
Hyper-V: Using Live Migration with Cluster Shared

Volumes in Windows Server 2008 R2
Updated: April 27, 2011
Applies To: Windows Server 2008 R2
This guide details the steps required to perform a live migration of Hyper-V™ virtual machines
from one node in a Windows Server® 2008 R2 failover cluster to another node.
Live migration overview

Live migration is a new Hyper-V feature in Windows Server 2008 R2, which requires the
failover clustering feature to be added and configured on the servers running Hyper-V. Hyper-V
and failover clustering can be used together to make a virtual machine that is highly available,
thereby minimizing disruptions and interruptions to clients. Live migration allows you to
transparently move running virtual machines from one node of the failover cluster to another
node in the same cluster without a dropped network connection or perceived downtime. In
addition, failover clustering requires shared storage for the cluster nodes. This can include an
iSCSI or Fiber-Channel Storage Area Network (SAN). All virtual machines are stored in the
shared storage area, and the running virtual machine state is managed by one of the nodes. For a
detailed overview of live migration and the benefits of using it, see Windows Server 2008 R2 &
Microsoft Hyper-V Server 2008 R2 - Hyper-V Live Migration Overview & Architecture.
Note
This guide assumes you are familiar with the requirements for using Hyper-V and
failover clustering, which are covered in Hyper-V Step-by-Step Guide: Hyper-V and
Failover Clustering.
If you need information on migrating clustered virtual machines to Windows

Server 2008 R2, see Migrating Clustered Virtual Machines to Windows Server 2008
R2.
Network recommendations for using live migration
The following recommendations will help you configure your networking environment for using
live migration:
 Network adapters. For each node of the failover cluster, use more than one
network adapter and configure at least one network adapter for the private
virtual network. We recommend that you configure a dedicated private
network with Gigabit speed for live migration traffic, and this network should
be separate from the network for private communication between the cluster
nodes, from the network for the virtual machine, and from the network for
storage. For information about the network traffic that can occur on a
network used for Cluster Shared Volumes, see “Understanding redirected I/O
mode in CSV communciation” in Requirements for Using Cluster Shared
Volumes in a Failover Cluster in Windows Server 2008 R2
Each node must also have a network adapter that carries Cluster Shared
Volumes communication, and in the network adapter properties, Client for
Microsoft Networks and File and Printer Sharing for Microsoft
Networks must be enabled to support SMB. For more information on the
network used for CSV communication, see Managing the network used for
Cluster Shared Volumes.
We recommend that you do not use the same network adapter for virtual
machine access and management. If you are limited by the number of
network adapters, you should configure a virtual local area network (VLAN) to
isolate traffic. VLAN recommendations include 802.1q and 802.p.
 Hardware and system settings. It is required that the storage hardware

on the failover cluster be identical and that the cluster nodes used for live
migration have virtualization-capable processors by the same processor
manufacturer. If this is not possible, it is recommended that the hardware
and system settings are as similar as possible to minimize potential
problems.
 Security policies. If possible, do not apply IPsec policies on a private

network for live migration because this can significantly impact the
performance of live migration.
 IP subnet configuration. Ensure that the source and destination nodes (for
the live migration) in the failover cluster are connected through the same IP
subnet. This is so the virtual machine can retain the same IP address after
live migration. For each network in a failover cluster where Cluster Shared
Volumes is enabled, all nodes must be on the same logical subnet, which
means that multisite clusters that use Cluster Shared Volumes must use a
VLAN.
For storage network recommendations, you should review the guidelines

provided by your storage vendor.
Node requirements for using Cluster Shared Volumes
The following recommendations will help you configure the nodes for using Cluster Shared
Volumes and live migration:
 Operating system. All nodes must run Windows Server 2008 R2 or Hyper-V
Server 2008 R2. All nodes must run the same operating system, except that
you can combine nodes running Hyper-V Server 2008 R2 in the same cluster
with nodes running the Server Core installation of Windows Server 2008 R2.
 Drive letter of system disk. On all nodes, the drive letter for the system
disk must be the same.
 Authentication protocol. The NTLM protocol must be enabled on all nodes.
Processor compatibility
If you are using different processor versions on the nodes in the cluster, live migration may fail.
To perform a live migration of a virtual machine to another physical computer with a different
processor, you must first select the Migrate to a physical computer with a different processor
version setting in Hyper-V Manager. This setting ensures that the virtual machine uses only the
features of the processor that are available on all versions of a virtualization-capable processor
by the same processor manufacturer. It does not provide compatibility between different
processor manufacturers. This allows you to move a running virtual machine to a physical
computer with different processor features without restarting the virtual machine. The setting is
also useful for high availability and backup and recovery scenarios because it makes it easier to
move a highly available virtual machine to another node in a cluster or restore the virtual
machine to different hardware.
Snapshots and virtual machines
You should avoid taking a snapshot of a running virtual machine. If you revert back to a
snapshot of a running virtual machine, the memory state is restored in addition to the disk.
Before reverting a clustered virtual machine back to a snapshot, you should first shut down the
virtual machine from Failover Cluster Manager, take a snapshot of the virtual machine, and
restart the virtual machine.
Attempting to back up a migrating virtual machine
Because live migration is a transition state, the Hyper-V VSS writer waits for the migration to
complete before continuing with backup. However, once migration is complete, the virtual
machine is no longer on the cluster node on which backup occurs. At this stage, backup
continues and correctly backs up the files (it can still access the files on the CSV volume), but it
is only a file copy. The VSS writer does not perform the steps that it usually would for an online
backup. You should be aware that the VSS writer does not return a failure error code to VSS, and
therefore, does not log any errors. However, it does log two warning messages that the virtual
machine is not found.
Important
When the Hyper-V VSS writer performs a backup in a failover cluster that uses CSV,
and the backup fails or is canceled, CSV continues in a redirected I/O mode. This
causes the I/O performance of all of the cluster nodes to suffer.
Steps for implementing live migration

Use the following steps to implement live migration:
 Install Windows Server 2008 R2 and enable the Hyper-V role on all nodes in
the failover cluster. For more information, see the Hyper-V Planning and
Deployment Guide.
 Install the Failover Clustering feature on all servers that you want to include
in the cluster. For more information, see the Hyper-V Step-by-Step Guide:
Hyper-V and Failover Clustering
 Configure as nodes in a failover cluster. For more information, see the

Failover Cluster Deployment Guide.
 Validate the cluster configuration. For more information, see the Failover
Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster.
 Configure Cluster Shared Volumes
 Set up a virtual machine for live migration
 Configure cluster networks for live migration
 Initiate a live migration of a virtual machine
Configure Cluster Shared Volumes
Cluster Shared Volumes are volumes in a failover cluster that multiple nodes can read from and
write to at the same time. The nodes coordinate the reading and writing activity so that the disk is
not corrupted. In contrast, disks (LUNs) in cluster storage that are not Cluster Shared Volumes
are always owned by a single node. Cluster Shared Volumes have the same requirements as non-
Cluster Shared Volumes disk resources. The storage location in the Cluster Shared Volumes is
under SystemDrive/ClusterStorage. When creating the virtual machine, we recommend that you
use this storage location.
Important
For Hyper-V to function properly when used with Cluster Shared Volumes, the
operating system (%SystemDrive%) of each server in your cluster must be set so
that it boots from the same drive letter as all other servers in the cluster. In other
words, if one server boots from drive letter C, all servers in the cluster should boot
from drive letter C.
It is recommended that you first validate the cluster configuration before configuring Cluster
Shared Volumes. For more information about how to validate a cluster configuration, see the
Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster and The
Microsoft Support Policy for Windows Server 2008 Failover Clusters.
Note
 The network connection that is used by Cluster Shared Volumes is fault

tolerant; therefore, if the network that is used by Cluster Shared Volumes
experiences problems, network traffic will be moved to another network.
 Cluster Shared Volumes can only be enabled once per cluster.
 By enabling Cluster Shared Volumes for a failover cluster, all nodes in the
cluster will be enabled to use shared volumes.
To enable Cluster Shared Volumes using Failover Cluster Manager
2. Right-click the failover cluster, and then click Enable Cluster Shared Volumes. Or,
under Configure (center pane), click Enable Cluster Shared Volumes. The Enable
Cluster Shared Volumes dialog box opens. Read and accept the terms and restrictions,
and click OK.
To add a disk to the Cluster Shared Volumes
2. If the console tree is collapsed, expand the tree under the cluster that you want to add a
disk to the Cluster Shared Volumes.
3. Click Cluster Shared Volumes.
4. Under Actions (on the right), click Add storage.
5. In Add Storage, select from the list of available disks, and click OK. The disk or disks
you selected appear in the Results pane for Cluster Shared Volumes.
The storage location appears as SystemDrive\ClusterStorage on all nodes of the failover cluster.
Under SystemDrive\ClusterStorage, a specific folder appears for each volume on the disk (or
disks) that was added to the Cluster Shared Volumes. You can view the list of volumes in
Failover Cluster Manager.
Managing the network used for Cluster Shared Volumes
Failover clusters include a setting to prioritize the networks used for communication between the
nodes in the cluster and for the network used for CSV traffic. You can identify the network used
for CSV traffic and change the settings of the network using the Windows PowerShell cmdlet,
Get-ClusterNetwork.
Each network in a cluster has two settings for network prioritization – Metric and AutoMetric.
The Metric setting is used to determine the priority of the network (the network with the lowest
value is the most preferred for CSV). The AutoMetric setting identifies whether the Metric
setting was set manually or automatically by the failover cluster. For private networks, the
Metric settings are between 1000 and 10,000, and for public networks, the Metric settings start at
10,000.
To manage the network used by Cluster Shared Volumes
1. Open PowerShell. Click Start, point to All Programs, click Windows Powershell 2.0,
and then click Windows Powershell 2.0.
The Failover Clustering feature must be installed on the computer on which you are
starting the PowerShell session. Or, you can use Remote Server Administration Tools for
Windows® 7 to run the PowerShell session.
2. To install the Failover Clustering feature, type:
Import-Module FailoverClusters
3. To identify the networks of a failover cluster and the properties of each network, type:
Get-ClusterNetwork | fl*
A list of cluster networks and their properties appears.
4. To change the metric setting to 1100 for the network named cluster network 1, type:
( Get-ClusterNetwork "Cluster Network 1" ).Metric = 1100
The AutoMetric setting changes from True to False after you manually change the Metric
setting. This is to prevent the failover cluster from automatically assigning a Metric
setting. If you want the cluster to start automatically assigning the Metric setting again,
change the AutoMetric setting back to True.
Set up a virtual machine for live migration
To set up a virtual machine for live migration, you need to do the following:
1. Create the virtual machine
2. Configure the virtual machine to use Cluster Shared Volumes
3. Reconfigure the automatic start action on the virtual machine
4. Make the virtual machine highly available
For information about how to perform these procedures, see Steps 6 and 7 in Hyper-V Step-by-
Step Guide: Hyper-V and Failover Clustering.
Note
When creating the virtual machine, we recommend that you configure the storage
location under SystemDrive/ClusterStorage in the Cluster Shared Volumes.
Configure cluster networks for live migration
Cluster networks are automatically configured for live migration. You can use Failover Cluster
Manager to perform this procedure.
To configure a cluster network for live migration
2. Expand Services and applications.
3. In the console tree (on the left), select the clustered virtual machine for which you want
to configure the network for live migration.
4. Right-click the virtual machine resource displayed in the center pane (not on the left), and
then click Properties.
5. Click the Network for live migration tab, and select one or more cluster networks to use
for live migration. Use the buttons on the right to move the cluster networks up or down
to ensure that a private cluster network is the most preferred. The default preference order
is as follows: networks that have no default gateway should be located first; networks that
are used by cluster shared volumes and cluster traffic should be located last.
Live migration will be attempted in the order of the networks specified in the list of
cluster networks. If the connection to the destination node using the first network is not
successful, the next network in the list is used until the complete list is exhausted, or there
is a successful connection to the destination node using one of the networks.
Note
o When you configure a network for live migration for a specific

virtual machine, the setting is global and therefore applies to all virtual
machines.
o If you have more than one cluster network listed in Network for
live migration, you should change the priority order to avoid having
live migration and Cluster Shared Volumes use the same network.
Initiate a live migration of a virtual machine
You can use either Failover Cluster Manager or PowerShell to initiate live migration to move a
virtual machine from one node to another node in a failover cluster.
Note
 Depending on the number of nodes in the failover cluster, you may be able to
use live migration to move more than one virtual machine at a time. However,
a cluster node can participate as the source or destination node in only one
live migration at a time. For example, if there are 4 nodes in the failover
cluster, then two live migrations can occur at the same time.
 If live migration fails, the virtual machine continues to operate on the source
node with no disruption.
The amount of time it takes to move a virtual machine using live migration is dependent on the
following items:
 The network connection speed and bandwidth that is available between the
source cluster node and the destination cluster node.
 The load on the source cluster node and the destination cluster node.
 The amount of RAM configured for the virtual machine.
To initiate live migration using Failover Cluster Manager
2. Expand Nodes.
3. In the console tree (on the left), select the node under which you want to move a clustered
virtual machine using live migration.
4. Right-click the virtual machine resource displayed in the center pane (not on the left), and
then click Live migrate virtual machine to another node.
5. Select the node that you want to move the virtual machine to. When migration is
complete, the virtual machine is running on the new node.
6. To verify that the virtual machine successfully migrated, you will see the virtual machine
listed under the new node (in Current Owner).
To initiate a live migration using PowerShell
1. Open PowerShell. Click Start, point to All Programs, click Windows Powershell 2.0,
and then click Windows Powershell 2.0.
The Failover Clustering feature must be installed on the computer on which you are
starting the PowerShell session. Or, you can use Remote Server Administration Tools for
Windows® 7 to run the PowerShell session.
2. To install the Failover Clustering feature, type:
Import-Module FailoverClusters
3. Type:
Get-Cluster “<Cluster Name>” | Move-ClusterVirtualMachineRole -Name

“<VM group name>” -Node “<Destination node name>”
Where:
o <Cluster Name> is the name of the cluster that the virtual machine is
included in.
o <VM group name> is the virtual machine resource group.
o <Destination node name> is the name of the destination node to

which you would like to move the virtual machine using live migration.
Troubleshooting live migrations

This section covers some of the issues that you may encounter when you are performing a live
migration. Before you review the troubleshooting items in this section, you should confirm that:
 The cluster validation tool has successfully run.
 The antivirus scan excludes files that are related to the virtual machine, such
as configuration files, VHDs, and snapshots. For more information, see the
Microsoft Support article Error codes when you create or start a virtual
machine on a Windows Server 2008-based computer that has Hyper-V.
Basic troubleshooting considerations
The following list covers some of the basic live migration troubleshooting issues.
 Make sure that all virtual network names are the same across the entire
cluster.
 If the cluster consists of both x86-based and x64-based processor computers,

note that live migration between both processor types will fail.
 If you initiate a second live migration before the clean-up of the first
migration is complete, the second migration may fail. You should wait for
several seconds before initiating the second migration.
 If a cluster service is restarted, or a virtual machine is moved and hosted by a

new RHS.exe cluster process, the network that is used for the migration
needs time to initialize. It may take up to 30 seconds for the network to be
ready. If you initiate a live migration during this time, it will fail with the error
“no migration network available”.
 Make sure that virtual switches and virtual switch ports do not have the same
name. Live migration will fail on virtual machines connected to virtual switch
ports that have the same name as the virtual switch.
Flowcharts for troubleshooting a live migration
Use the following two flowcharts to troubleshoot a live migration.

Collecting configuration information
The following list outlines the configuration information that will help diagnose troubleshooting
issues.
Cluster information:
 Determine whether Cluster Shared Volumes is used. If so, note how many
volumes.
 Determine the CPU model of each cluster node and verify that they are
compatible.
 Analyze the cluster validation report.
 Determine the number of networks and each network’s configuration. For

example, 1GB or 10GB, IPv4 or IPv6, and whether IPsec is used.
Network information:
 Determine whether the network adapters are capable of TCP Offload

(Chimney), and whether TCP Offload (Chimney) is enabled in the
management and guest operating systems.
 Determine whether the network adapters are bound to a virtual switch that is
capable of virtual machine queue (VMQ).
 Determine whether the network adapters are teamed.
Virtual machine information:
 Determine how many virtual machines have been made highly available, and
whether the virtual machines are using Cluster Shared Volumes.
 Determine what operating systems the virtual machines are using and what
the workload is.
Retrieving event log information
To help diagnose troubleshooting issues, you can retrieve Hyper-V and cluster event log
information.
 To enable the high availability analytic log, type the following command at a
command prompt:
Wevtutil sl “<Log Name>” /e:true /q
Where:
<Log Name> is the name of the high availability analytic log to enable.
 To retrieve information from the log, type the following command at a

command prompt:
Wevtutil epl query.txt /sq:true <Log Name>.evtx
Where:
<Log Name> is the name of the high availability analytic log from which to
retrieve information.
Query.txt code:
 <QueryList>
 <Query Id="0" Path="System">
 <Select Path="System">*[System[Provider[@Name='Microsoft-Windows-
Hyper-V-Hypervisor']]]</Select>
 <Select Path="Microsoft-Windows-Hyper-V-Config-Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-High-Availability-
Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-High-Availability-
Analytic">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-Hypervisor-Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-Integration-
Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-Network-Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-SynthStor-Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-SynthNic-Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-Image-Management-Service-
Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-VMMS-Admin">*</Select>
 <Select Path="Microsoft-Windows-Hyper-V-Worker-Admin">*</Select>
 </Query>
 </QueryList>
 To retrieve information from cluster event logs, type the following from a
PowerShell session:
Get-ClusterLog or Get-ClusterLog –Destination <logdir>
Where:
<Logdir> is the location of the event logs.
To retrieve information from cluster event logs using Cluster.exe at a

command prompt, type:
Cluster.exe log /g /copy:<logdir>

Hyper - V Getting Started

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Hyper - V Getting Started

Încărcat de

Drepturi de autor:

Formate disponibile

Hyper-V Release Notes

Applies To: Windows Server 2008

Windows Server 2008 and Windows Ser...

Browse Windows Server Technologies