Hyper-V
Content
Hands-on Guide:
Understanding
Hyper-V
in Windows Server 2012
Brien Posey
Pete Zerger, Chris Henley
Understanding Hyper-V in Windows Server 2012
Contents
Chapter 1. An Introduction to Hyper-V 3.0
Chapter 2. Failover Clustering
3
30
Chapter 3. Migrations 84
Chapter 4. Managing Virtual Machine Failover
123
Chapter 5. PowerShell Management
142
Coming soon:
Chapter 6. Virtual Machine Management
Chapter 7. P2V conversions
Chapter 8. Replication
Chapter 9. Hyper-V Management
Chapter 10. Networking
Chapter 11. Automation
Chapter 12. Backup
2
Understanding Hyper-V in Windows Server 2012
Chapter 1
An Introduction
to Hyper-V 3.0
This chapter is designed to get you started quickly with
Hyper-V 3.0. It starts with a discussion of the hardware
requirements for Hyper-V 3.0 and then explains a basic
Hyper-V–deployment followed by an upgrade from
Hyper-V 2.0 to Hyper-V 3.0. The chapter concludes with
a demonstration of migrating virtual machines from
Hyper-V 2.0 to Hyper-V 3.0
3
Understanding Hyper-V in Windows Server 2012
Hyper-V 3.0 flavors
Before we get started, it is worth noting that like its predecessors, Hyper-V
3.0 comes in two different flavors. Microsoft offers a standalone version
of Hyper-V, or you can operate Hyper-V as a server role on top of Windows
Server 2012. This book deals with Hyper-V exclusively as a server role.
Hardware requirements
According to Microsoft, the minimum hardware required for deploying
Windows Server 2012 includes:
• A 64-bit processor operating at 1.4 GHz or higher
• 512 MB of RAM
• 32 GB of hard disk space
• A DVD Drive
• A monitor and video card with a minimum display resolution of 800 x 600
• Keyboard and mouse (or other compatible pointing device)
• Internet access
Because Hyper-V is designed to use the server’s hardware to host a number
of virtual machines, the minimum system requirements are not suitable
for Hyper-V. Specifically, you will need more memory and hard disk space,
and it’s advisable to have a server with multiple sockets and/or multiple CPU
cores. The servers used in the development of this book were equipped with
the following:
• An 8-core, 64-bit CPU
• 32 GB of RAM
• A 500-GB hard drive used to store the host operating system.
• Four 1-TB hard drives configured as a RAID 5 array
In addition to the hardware requirements listed above, the CPU must support
hardware-level virtualization. It is worth noting that virtualization has been
disabled by default on many servers, so you may need to enable virtualization
through the system BIOS, as shown in Figure 1.1. If your server’s BIOS contains
a setting for Data Execution Prevention (DEP), you will need to enable that
setting as well.
4
Understanding Hyper-V in Windows Server 2012
Figure 1.1
You may need to manually enable virtualization in the server’s BIOS.
Installing Windows Server 2012
and Hyper-V 3.0
Setting up a clean installation of Windows Server 2012 and Hyper-V 3.0 is
relatively simple and straightforward. First, install Windows Server 2012 by
completing these steps:
1. Boot your server from the Windows Server 2012 installation media.
2. When the Windows Server 2012 splash screen launches, verify that
the language, time and currency format, and keyboard or input methods
are correct (Figure 1.2).
Figure 1.2
Verify your installation preferences.
5
Understanding Hyper-V in Windows Server 2012
3. Click Next.
4. Click Install Now (Figure 1.3).
Figure 1.3
Click Install Now.
5. Choose the operating system that you want to install (Figure 1.4). It is
worth noting that a default Windows Server 2012 does not include
the GUI. If you want to use the GUI then do not choose the Server
Core option. Although Server Core is Microsoft’s preferred method
for deploying Windows Server 2012, it is easier to manage Hyper-V
through a GUI. Therefore, the instructions found throughout this book
will assume that you are using the GUI. If you are interested in Server Core
deployments, see Chapter 5 for a discussion about managing Hyper-V
through Windows PowerShell.
Figure 1.4
Choose the edition of Windows Server 2012 that you want to install.
6
Understanding Hyper-V in Windows Server 2012
6. Accept the license agreement and click Next (Figure 1.5).
Figure 1.5
You must accept Microsoft’s license agreement.
7. When prompted for the type of installation you want to perform, choose
the option for Custom: Install Windows Only (advanced) (Figure 1.6).
Figure 1.6
Choose the option to perform a custom installation.
8. Choose the volume on which you want to install Windows and click Next
(Figure 1.7).
7
Understanding Hyper-V in Windows Server 2012
Figure 1.7
Select the drive or volume on which you want to install Windows Server 2012.
9. Setup will now begin the installation process (Figure 1.8). After
the Windows installation completes , you must work through a separate
process to install Hyper-V.
Figure 1.8
The installation process will now begin.
Deploying Hyper-V 3.0
After Windows Server 2012 is up and running, the next step is to install
the Hyper-V role. To do so, follow these steps:
1. Open the Server Manager if it is not already open.
2. Choose the Add Roles and Features command from the Manage menu
(Figure 1.9).
8
Understanding Hyper-V in Windows Server 2012
Figure 1.9
Choose the Add Roles and Features command.
3. When the Add Roles and Features Wizard launches, click Next to bypass
the wizard’s Welcome screen.
4. Click Next.
5. Choose the Role-Based or Feature-Based Installation option (Figure 1.10).
Figure 1.10
Choose the Role Based or Feature Based Installation option.
6. Click Next.
7. On the Server Selection screen, make sure that the local server is selected
and click Next (Figure 1.11).
9
Understanding Hyper-V in Windows Server 2012
Figure 1.11
Make sure that your local server is selected.
8. Select Hyper-V from the list of server roles (Figure 1.12).
Figure 1.12
Select the Hyper-V role.
9. If you are prompted to install additional features, click the Add
Features button.
10. Click Next.
10
Understanding Hyper-V in Windows Server 2012
11. When the wizard displays the list of available features, click Next.
12. Click Next on the Hyper-V introductory screen.
13. Select the network adapters that you want to make available to your
virtual machines. Be sure to reserve at least one network adapter for host
management traffic (Figure 1.13).
Figure 1.13
Be sure to reserve a network adapter for host management traffic.
14. Click Next.
15. At this point you will see a screen asking if you want to allow the server to
send and receive live migrations of virtual machines. Live migrations are
discussed in Chapter 3, so for now just click Next to accept the defaults.
16. When prompted, click Next to accept the default stores.
17. When the Confirmation screen is displayed, click the Install button.
Post deployment tasks
After the installation process completes, you may need to perform a number of
post-deployment tasks, which might include:
• Configure the host’s IP address
• Rename the host
• Join the host to a domain
The sections that follow will walk you through performing each of these tasks.
11
Understanding Hyper-V in Windows Server 2012
Configure the host’s IP address
In most cases, Hyper-V host servers need to have at least one NIC that is
dedicated to hosting management traffic. As a best practice, you should assign
a static IP address to this NIC. You can assign an IP address to the server’s
management NIC as follows:
1. Move the mouse to the lower left corner of the screen and right click.
Choose the Control Panel option from the right-click menu.
2. When the Control Panel appears, click on Network and Internet.
3. Click on Network and Sharing Center.
4. Click on the Change Adapter Settings link.
5. Right click on the icon representing your management NIC and choose
the Properties command from the shortcut menu.
6. Assuming that IPv4 is being used, select the Internet Protocol Version 4
(TCP/IPv4) option and click the Properties button (Figure 1.14).
7. Enter the IP address that you want to assign to the NIC and click OK
(Figure 1.15).
Figure 1.14
Select Internet Protocol Version 4 (TCP/IPv4) and click the Properties button.
12
Understanding Hyper-V in Windows Server 2012
Figure 1.15
Provision your management NIC with a static IP address and click OK.
Rename the host
Windows Server 2012 automatically assigns a unique host name to each server,
but it is generally advisable to assign a more meaningful name to each Hyper-V
host. Doing so will make the host management process easier. To assign a new
name to your Hyper-V host server, follow these steps:
1. M
ove the mouse to the lower left corner of the screen and right click.
Choose the System option from the right-click menu.
2. When the System properties sheet appears, click on the Change Settings
link (Figure 1.16).
13
Understanding Hyper-V in Windows Server 2012
Figure 1.16
Click the Change Settings link.
3. Verify that the Computer Name tab is selected and then click the Change
button (Figure 1.17).
Figure 1.17
Click the Change button.
14
Understanding Hyper-V in Windows Server 2012
4. Enter a new name for the server and click OK (Figure 1.18).
Figure 1.18
Enter a new computer name and click OK.
5. Click OK to acknowledge the message indicating that you must restart
your computer to apply the new name.
6. Click Close.
7. When prompted, click Restart Now (Figure 1.19).
Figure 1.19
You must restart the server before your changes will take effect.
15
Understanding Hyper-V in Windows Server 2012
Join the host to a domain
The process of joining a Windows Server 2012 host to a domain is very similar
to that used in joining a Windows Server 2008 R2 host to a domain. To join
a domain, follow these steps:
1. From the Metro interface, click the Desktop tile.
2. Move your mouse to the lower left corner of the screen and right-click on
the Start tile.
3. Click on the System option on the right-click menu.
4. When the System dialog box appears, click on the Change Settings link
(Figure 1.16).
5. When the System Properties sheet appears, go to the Computer Name
tab and click the Change button (Figure 1.17).
6. Select the Domain option and enter the fully qualified domain name
(Figure 1.18).
7. Click OK.
8. When prompted, enter a set of administrative credentials for the domain.
9. Click OK to clear the message indicating that the computer has been
joined to a domain.
10. Reboot the server (Figure 1.19).
Performing an in-place upgrade from
Hyper-V 2.0
If your organization is currently running Hyper-V 2.0, it is usually possible to
perform an in-place upgrade to Hyper-V 3.0. In preparation for an upgrading
a standalone Hyper-V 2.0 server, you must shut down any virtual machines that
are currently running. To complete the upgrade, follow these steps:
1. Shut down any virtual machines that are running on the server to be
upgraded. If any virtual machines are left running, the Compatibility
Report will prevent the upgrade from continuing (Figure 1.20).
16
Understanding Hyper-V in Windows Server 2012
Figure 1.20
You must shut down the virtual machines prior to beginning the upgrade.
2. With Windows Server 2008 R2 still running, insert your Windows Server
2012 installation media and run the Setup program.
3. When the Windows Server 2012 splash screen appears, click Install Now
(Figure 1.21).
Figure 1.21
Click the Install Now button.
4. When prompted, click on the option to go online to install updates
(Figure 1.22).
17
Understanding Hyper-V in Windows Server 2012
Figure 1.22
You should go online to get the latest updates.
5. Enter your product key and click Next.
6. Select whether you want to perform a server core deployment or a fullserver deployment that includes the GUI (Figure 1.23). It is worth
noting that Windows Server 2012 is designed to perform a server
core deployment by default. However, you cannot perform an in-place
upgrade of a full Windows Server deployment (with a GUI) to a server
core deployment. If you want a server core deployment, you will have to
upgrade to the full GUI version of Windows Server 2012 and then uninstall
the GUI later. The instructions provided in this book assume that you will
be working with a full GUI-based installation. If you are interested in using
Server Core, see Chapter 5 for a discussion of how to manage Hyper-V
from PowerShell.
Figure 1.23
Choose the edition of Windows Server 2012 that you want to install.
18
Understanding Hyper-V in Windows Server 2012
7. Click Next.
8. When prompted, accept the license agreement and click Next
(Figure 1.24).
Figure 1.24
You must accept Microsoft’s license agreement.
9. Choose the option to Upgrade: Install Windows and keep files, settings,
and applications (Figure 1.25).
Figure 1.25
Choose the option to upgrade the existing operating system.
10. Take a moment to review the Compatibility Report, which informs you
of issues you need to address prior to moving forward with the upgrade
(Figure 1.26). When you are finished, click Next.
19
Understanding Hyper-V in Windows Server 2012
Figure 1.26
Take a moment to read the compatibility report.
11. At this point, Windows will be installed. The remainder of the upgrade
process is automated.
Migrating virtual machines from Hyper-V
2.0 to Hyper-V 3.0
One of the big disadvantages to performing an in-place upgrade is that it can
cause virtual machines to be down for a significant amount of time. One way
to reduce the amount of time during which virtual machines are unavailable
is to perform a migration rather than an upgrade. A migration involves
deploying Hyper-V 3.0 onto new hardware while your existing hardware
continues to run Hyper-V 2.0. Once the deployment is complete, you can
migrate the individual virtual machines from the Hyper-V 2.0 deployment to
the Hyper-V 3.0 deployment.
Exporting the virtual machines
The first step in migrating virtual machines from Hyper-V 2 to Hyper-V 3 is to
export the virtual machines to either a network share or to removable media.
To complete the export process, follow these steps:
1. Open the Hyper-V Manager on the Hyper-V 2.0 Server.
2. Select the virtual machines that you want to export (Figure 1.27).
20
Understanding Hyper-V in Windows Server 2012
Figure 1.27
Select the virtual machines that you wish to export.
3. Click on the Export link.
4. Specify a path to write the exported content (Figure 1.28). Be sure to
choose a location with plenty of free storage space.
Figure 1.28
Enter an export path and click the Export button.
5. Click Export.
You can monitor the progress of the export by scrolling the Hyper-V Manager
to view the virtual machine Status (Figure 1.29).
21
Understanding Hyper-V in Windows Server 2012
Figure 1.29
You can monitor the export process through the Hyper-V Manager.
Importing virtual machines
Importing virtual machines into Hyper-V 3.0 is a relatively easy
and straightforward process. You can import one or more virtual machines
as follows:
1. Open the Hyper-V Manager.
2. Right-click on the name of the Hyper-V host and select the Import Virtual
Machine command from the right-click menu (Figure 1.30).
Figure 1.30
Right click-on your the server and select the Import Virtual Machine command from
the right‑click menu.
3. When the Import Virtual Machine wizard launches, click Next to bypass
the wizard’s Welcome screen.
4. Click the Browse button.
22
Understanding Hyper-V in Windows Server 2012
5. Navigate to the folder containing the virtual machine that you want to
import and click the Select Folder button.
6. Choose the virtual machine that you want to import (Figure 1.31).
Figure 1.31
Select the virtual machine that you want to import.
7. Click Next.
8. The next screen asks you to choose an import type (Figure 1.32). Unless
you have a compelling reason to choose one of the other options, it is
usually best to choose the option to Copy the Virtual Machine (Create
a New Unique ID). This allows the exported virtual machine to be
re‑imported later should the need ever arise.
23
Understanding Hyper-V in Windows Server 2012
Figure 1.32
Choose the appropriate import type.
9. Click Next.
10. The following screen asks if you want to store any of the virtual machine
components in a different location. Generally, it is safe to accept
the defaults. Click Next.
11. The wizard will now ask where you want to store the imported Virtual
Hard Disks. Select a folder on an appropriate volume and click Next.
12. Verify the summary information screen and click Finish (Figure 1.33).
24
Understanding Hyper-V in Windows Server 2012
Figure 1.33
The import process begins when you click Finish.
The import process can take a considerable amount of time to complete,
depending upon the size of the virtual machine and the speed of the hardware.
When the import process finishes, you should see the newly imported virtual
machine within the Hyper-V Manager.
Before you power-up the newly imported virtual machine, you need to connect
the virtual machine to a virtual switch. To do so, right click on the virtual
machine and choose the Settings command from the right-click menu. When
the Settings page appears, click on the Network Adapter option and then
connect the virtual machine to the appropriate virtual switch (Figure 1.34).
When you have finished, click OK.
25
Understanding Hyper-V in Windows Server 2012
Figure 1.34
You must connect your virtual machine to a virtual switch.
This completes the process of importing a virtual machine. Previous versions
of Hyper-V required you to re-enter the IP address configuration for each
virtual network adapter. However, Hyper-V 3.0 preserves the virtual machine’s
IP address configuration. The only change that you might need to make to
the virtual machine is to install an updated version of the Hyper-V Integration
Services.
What about clusters?
This chapter has discussed clean Hyper-V installations as well as the process
for upgrading a Hyper-V 2.0 server to Hyper-V 3.0. Although these techniques
are certainly valid, organizations that are currently running Hyper-V are often
using a clustered environment.
The process of building a Hyper-V cluster is discussed in detail in Chapter 2. This
section explains what is involved in upgrading a Hyper-V 2.0 cluster to Hyper-V
3.0—a process that is not entirely intuitive.
Microsoft’s preferred method for performing a cluster upgrade involves building
an entirely new cluster. The basic idea is to create a cluster out of servers that are
running Windows Server 2012. If you lack the budget to build a completely new
cluster, you can start small by building the new cluster with a minimum number
of cluster nodes and using low-end hardware if necessary. After the migration
26
Understanding Hyper-V in Windows Server 2012
process is complete, you can always install Windows Server 2012 onto your
existing cluster hardware, join those servers to the new cluster and then remove
the temporary, low-end servers from the cluster. Don’t worry too much about
exceeding the maximum cluster size during the migration process, because
Windows Server 2012 allows up to 63 cluster nodes.
As you probably know, Hyper-V 2.0 clusters depend on the use of Cluster Shared
Volumes. When you build the new Hyper-V 3.0 cluster, you must attach the
cluster nodes to the existing cluster shared volume (see Chapter 2 for details).
At this point, both the Hyper-V 2.0 cluster and the Hyper-V 3.0 cluster should be
tied into the same Cluster Shared Volume.
Once the Hyper-V 3.0 cluster is in place, verify that the Hyper-V 2.0 cluster is
still functional and that the virtual machines are still running (there is no reason
why they shouldn’t be, because the cluster has not been modified). Now, open
the Failover Cluster Manager on one of your Windows Server 2012 servers
and follow these steps:
1. Right-click on the cluster name and choose the More Actions | Migrate
Roles commands from the right-click menus (Figure 1.35).
Figure 1.35
Choose the Migrate Roles option.
2. When the Migrate a Cluster Wizard launches, click Next to bypass
the wizards’ Welcome screen.
3. When prompted, enter the name of the old cluster from which you plan to
migrate the virtual machines (Figure 1.36).
27
Understanding Hyper-V in Windows Server 2012
Figure 1.36
Enter the name of your Hyper-V 2.0 cluster.
4. Select the virtual machines that you plan to migrate and click Next
(Figure 1.37).
Figure 1.37
Choose the virtual machines that you want to migrate.
5. Choose the Virtual Network Switch that the virtual machines should use
after they have been migrated to the new cluster and click Next.
28
Understanding Hyper-V in Windows Server 2012
6. The next screen provides an analysis of the migration. You can click
the View Report button to see the full Failover Cluster Pre-Migration
Report. It is worth noting that the report indicates that the cluster group
and the available storage cannot be migrated. This is perfectly normal
and acceptable.
7. Close the report and click Next.
8. Take a moment to verify the information displayed on the Confirmation
screen and click Next.
9. When the migration completes, click Finish.
Please keep in mind that Windows Server 2012 does not perform a live migration
of the virtual machines. When the migration completes, the virtual machines are
still running on the Hyper-V 2.0 cluster, so there are a couple of things that you
need to do to complete the process.
First, shut down the virtual machines on the Hyper-V 2.0 server. Second,
disconnect the Hyper-V 2.0 cluster nodes from the shared storage. If you fail to
do this, virtual machine corruption can occur. Finally, start the virtual machines
on your new cluster. Once the virtual machines are up and running, it is safe to
destroy your Hyper-V 2.0 cluster and re-provision the host servers for use in
the new cluster.
29
Understanding Hyper-V in Windows Server 2012
Chapter 2
Failover Clustering
Chapter 2 is designed to familiarize you with your options
for Hyper-V clustering. Hyper-V 3.0 allows you to build
a cluster with or without shared storage, and this chapter
walks you through both methods. In addition, you will
learn how to provision storage using a new Windows
Server 2012 feature called Windows Storage Spaces.
30
Understanding Hyper-V in Windows Server 2012
Perhaps the most important concept to understand with regard to server
virtualization is that of clustering. The reason for this is simple: Server
virtualization places an increased importance on server hardware. In a traditional
physical datacenter the failure of a single server is typically regarded as
an inconvenience, but is rarely catastrophic. In a virtual datacenter, however,
this may not be the case. Each physical server hosts multiple virtual machines.
Therefore, if a physical server fails then all of the virtual machines residing on that
server will also fail. Hence, the failure of a single physical host can cause a major
outage. The only way to protect against this type of failure is through the use of
failover clustering.
Failover clustering spreads a virtualized workload across multiple physical hosts.
That way if a host server fails, the virtual machines can fail over to a different host
server within the cluster and remain online in spite of the failure.
Failover clustering is not new to Hyper-V 3.0, but Microsoft has made significant
improvements to failover clustering. Many of these improvements are related
to scalability. The table below compares a Hyper-V 2.0 cluster to a Hyper-V 3.0
cluster in terms of scalability.
Hyper-V 2.0
Hyper-V 3.0
384
1024
Maximum number of
virtual machines in
a cluster
1000
4000
Maximum number of
hosts per cluster
16
63
1 TB
2 TB
The maximum number of
virtual machines per host
that can be powered on at
any given time
Maximum RAM per
host server
Another major improvement that Microsoft has made with regard to failover
clustering is that they have changed the storage requirements. Prior to Hyper-V
3.0, a Hyper-V cluster depended on the use of a Cluster Shared Volume.
A Cluster Shared Volume is a shared storage volume that physically contains all
of the virtual machine components. Because the storage is shared, it is physically
accessible to all of the cluster nodes. You can see an example of shared storage
architecture in Figure 2.1.
31
Understanding Hyper-V in Windows Server 2012
Figure 2.1
Previous versions of Hyper-V required failover clusters to make use of shared storage.
In Hyper-V 3.0, shared storage is no longer required for failover clustering.
A failover cluster can be built without the need for a Cluster Shared Volume.
In those types of clusters, the virtual machines can reside on local direct
attached storage or they can even reside on certain types of file servers.
The fact that you can create failover clusters without a Cluster Shared Volume is
good news for smaller organizations because the cost of shared storage often
puts clustered virtualization hosts financially out of reach. Even so, Microsoft
recommends that Hyper-V 3.0 failover clusters make use of failover clusters
whenever possible . This chapter will demonstrate the process of building
failover clusters both with and without shared storage.
Cluster planning
Before you begin constructing a failover cluster you will need to do some
planning. Obviously you will need to decide whether the cluster will
use shared storage, you’ll need to take into account a number of other
considerations, including:
• Domain membership — Domain membership isn’t an absolute
requirement for cluster nodes, but the configuration process is a lot easier
if all of the cluster nodes are members of a common Active Directory
domain. Domain membership allows Kerberos authentication to be
used. This chapter will assume that all cluster nodes have been joined
to a common Active Directory domain.
• Node names — Just as the cluster requires a cluster name, each cluster
node requires a unique computer name. Although Windows Server 2012
assigns computer names automatically, it is highly recommended that you
assign computer names that are more descriptive. Doing so makes it easier
to figure out which node you are working on. The cluster nodes used in
the examples in this chapter will be named Lab1, Lab2 and Lab3.
32
Understanding Hyper-V in Windows Server 2012
• Cluster name — The configuration process requires that a unique name
be assigned to the cluster. The name you choose should be different from
any of the computer names that are used within your Active Directory.
• Cluster node hardware — Another important consideration is the cluster
nodes themselves. The nodes do not have to use identical hardware, but
they should all use the same CPU architecture and ideally they should be
equipped with comparable amounts of memory.
• Number of nodes — You also need to decide how many nodes to use
in your cluster. In this chapter you will be building a Majority Node Set
Cluster. It is best to use an odd number of cluster nodes whenever possible
because a Majority Node Set Cluster requires half of the nodes plus one
to remain online during a failure in order for the cluster to retain quorum.
It is technically possible to build a failover cluster out of two cluster nodes
(plus a file share witness), but it's recommended that you always use at
least three cluster nodes. Your cluster can contain as many as 63 nodes.
Of course, most clusters use far fewer than 63 nodes, and you always have
the option of adding additional cluster nodes later until the maximum
number of nodes has been reached.
• Network adapters — Hyper-V is very flexible in terms of the network
adapter requirements for cluster nodes. However, it is generally
recommended that each cluster node have a minimum of three network
adapters. You should reserve one adapter should be reserved for
management traffic and another adapter for cluster traffic. The third
(and any additional adapters) are used for virtual machine traffic.
• Node IP addresses — As a best practice, you should assign a static IP
address to each cluster node’s management NIC. However, you will also
need to decide how you want to handle IP address assignment for the
other NICs.
• Cluster IP address — In addition to the IP addresses assigned to physical
NICs you must assign a static IP address to the cluster. This IP address
is used to communicate with the cluster as a whole rather than with
an individual cluster node.
Building a failover cluster without
shared storage
As previously mentioned, it is possible to build a failover cluster without using
shared storage. This part of the chapter will walk you through the process. You
will be building a Majority Node Set cluster consisting of three cluster nodes.
Keep in mind, however, that if it is within your budget, you should use shared
storage whenever possible, as Microsoft recommends.
This section assumes that you have installed Windows Server 2012
onto each cluster node, joined the cluster nodes to an Active Directory
domain, and provisioned each node with an appropriate computer name
and the necessary IP addresses.
33
Understanding Hyper-V in Windows Server 2012
Installing the failover clustering feature
The first step in the configuration process is to install the Failover Clustering
feature onto each cluster node. You can accomplish this task by following
these steps:
1. Open the Server Manager
2. Choose the Add Roles and Features option from the Manage menu.
3. When the Add Roles and Features Wizard starts, click Next to bypass
the welcome screen.
4. Choose the Role-Based or Feature-Based Installation option and click
Next.
5. Verify that the correct server is selectedand click Next (Figure 2.2).
Figure 2.2
You must install the Failover Clustering feature onto each of the cluster nodes.
6. When the wizard displays the list of server roles, click Next.
7. Select Failover Clustering from the list of features (Figure 2.3). If the wizard
prompts you to install additional features, click the Add Features button.
34
Understanding Hyper-V in Windows Server 2012
Figure 2.3
Select the Failover Clustering feature.
8. Click Next.
9. Click Install.
10. When the installation process completes, click Close.
Building a Majority Node Set Cluster
Now that the Failover Clustering Service has been installed, the next step in
the process is to build the failover cluster. The steps listed in this section only
need to be performed on one of the cluster nodes. To create the failover cluster,
follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, click on the Create Cluster link,
found in the Actions pane (Figure 2.4). Windows will launch the Create
Cluster Wizard.
35
Understanding Hyper-V in Windows Server 2012
Figure 2.4
Click on the Create Cluster link.
4. Click Next to bypass the wizard’s Welcome screen.
5. Specify the names of the servers that you want to include in the cluster
(Figure 2.5).
Figure 2.5
You should specify all of the nodes that you want to include in the cluster.
36
Understanding Hyper-V in Windows Server 2012
6. Click Next.
7. You should now see a message indicating that the cluster has not yet been
validated. Choose the option to run the validation tests and click Next
(Figure 2.6). Windows will launch the Validate a Cluster Wizard.
Figure 2.6
You must validate the cluster before you can create it.
8. Click Next to bypass the wizard’s Welcome screen.
9. Choose the Run All Tests (Recommended) option and click Next.
10. Click Next to begin the validation tests.
11. When the validation tests complete, take a moment to view the report
and review any errors or warnings (Figure 2.7). Click Finish.
37
Understanding Hyper-V in Windows Server 2012
Figure 2.7
Review the validation report and check for any errors or warnings.
12. When prompted, enter a name for the cluster and assign an IP address
to the cluster (Figure 2.8). The name and IP address that you use should be
unique and will be used to identify the cluster as a whole.
Figure 2.8
You must assign a unique name and static IP address to the cluster.
38
Understanding Hyper-V in Windows Server 2012
13. Click Next.
14. Take a moment to verify the information presented on the confirmation
screen and click Next.
15. You should see a message indicating that the cluster was created
successfully. Click Finish to close the wizard.
Installing the Hyper-V role
The next step in the process is to install the Hyper-V role. This role must be
installed onto each of the cluster nodes. To complete this process, follow
these steps:
1. Open the Server Manager.
2. Choose the Add Roles and Features command from the Manage menu.
3. When the Add Roles and Features wizard appears, click Next to bypass
the wizard’s Welcome screen.
4. Make sure that the Role-Based or Feature-Based Installation option is
selected and click Next.
5. Select the server on which you want to deploy the Hyper-V role and click
Next (Figure 2.9).
Figure 2.9
Choose the server on which you want to deploy the Hyper-V role.
39
Understanding Hyper-V in Windows Server 2012
6. Select the Hyper-V option from the list of roles (Figure 2.10).
Figure 2.10
Select the Hyper-V role and click Next.
7. If you are prompted to add additional features, click the Add Features
button.
8. Click Next.
9. Click Next.
10. Click Next.
11. Select the network adapters that you want to connect to the virtual
switch (Figure 2.11). You can select multiple network adapters, but as
a best practice you should reserve a network adapter for management
traffic and reserve an adapter for cluster communications (such as cluster
heartbeats and live migration traffic).
40
Understanding Hyper-V in Windows Server 2012
Figure 2.11
Select the network adapters that you want to connect to the Hyper-V virtual switch.
12. Click Next.
13. Select the checkbox for Allow this Server to Send and Receive Live
Migrations of Virtual Machines (Figure 2.12).
Figure 2.12
Cluster nodes must be able to live migrate virtual machines.
41
Understanding Hyper-V in Windows Server 2012
14. Select the authentication protocol to be used by live migration traffic. If
the cluster nodes reside in the same Active Directory domain, then you
should use the Kerberos protocol. Kerberos is more secure than CredSSP
and the configuration process is easier.
15. Click Next.
16. Click Next to accept the default store location.
17. Take a moment to verify the information that is displayed on
the Confirmation screen and then click Install.
18. When the installation process completes, click Close and then reboot
the server.
19. Repeat these steps for each node in the cluster.
Making Hyper-V fault tolerant
So far you have installed the Failover Clustering feature and the Hyper-V role.
Even so, Hyper-V is not yet fault tolerant. Fault tolerance is implemented on
a per-virtual-machine basis. That being the case, it’s a good idea to create
some virtual machines. Then you can make your virtual machines fault tolerant
by following these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager from the list of tools.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster name> | Roles
(Figure 2.13).
Figure 2.13
Navigate through the Failover Cluster Manager to Failover Cluster Manager | <your cluster
name> | Roles.
4. Click the Configure Role link, found in the Actions pane.
5. Windows will launch the High Availability Wizard. Click Next to bypass
the wizard’s Welcome screen.
6. The next screen lists a variety of server roles. Select the Virtual Machine
role from the list and click Next (Figure 2.14).
42
Understanding Hyper-V in Windows Server 2012
Figure 2.14
Select the Virtual Machine option and click Next.
7. Select the virtual machines that you wish to make fault tolerant and click
Next (Figure 2.15).
Figure 2.15
Select the virtual machines that you wish to make fault tolerant and click Next.
43
Understanding Hyper-V in Windows Server 2012
8. Verify the information displayed on the confirmation screen and click Next.
9. When the process completes you should see a message confirming that
high availability was successfully configured. Click the View Report button
to examine the report. Click Finish.
After the virtual machines become fault tolerant, you should see them listed
in the Failover Cluster Manager’s Roles container (Figure 2.16). Likewise,
the Hyper-V Manager should list the virtual machine as being clustered
(Figure 2.17).
Figure 2.16
The virtual machine should now be listed in the Failover Cluster Manager.
Figure 2.17
The Hyper-V Manager should list the virtual machine as being clustered.
44
Understanding Hyper-V in Windows Server 2012
Building a failover cluster using
shared storage
Even though you can build a Hyper-V 3.0 cluster without the need for shared
storage, Microsoft’s preferred method for building a Hyper-V failover cluster
still involves the use of a Cluster Shared Volume. In this section you will learn
how to build a majority node set cluster consisting of three cluster nodes
and a fourth server that hosts the Cluster Shared Volume for the cluster.
This section assumes that you have installed Windows Server 2012
onto each cluster node, joined the cluster nodes to an Active Directory
domain, and provisioned each node with an appropriate computer name
and the necessary IP addresses.
The method or building a failover cluster that utilizes shared storage is
similar to that used for a shared nothing cluster. Even so, this section will walk
you through the procedure in its entirety (including procedures that were
demonstrated in the previous section) because the procedures have to be
performed in a certain order.
Installing the Failover Clustering feature
The first step in the configuration process is to install the Failover Clustering
feature onto each cluster node. You can accomplish this task by following
these steps:
1. Open Server Manager
2. Choose the Add Roles and Features option from the Manage menu.
3. When the Add Roles and Features Wizard starts, click Next to bypass
the welcome screen.
4. Choose the Role-Based or Feature-Based Installation option
and click Next.
5. Verify that the correct server is selected and click Next.
6. When the wizard displays the list of server roles, click Next.
7. Select Failover Clustering from the list of features (Figure 2.18).
If the wizard prompts you to install additional features, click the Add
Features button.
45
Understanding Hyper-V in Windows Server 2012
Figure 2.18
Select the Failover Clustering feature and click Next.
8. Click Next.
9. Click Install.
10. When the installation process completes, click Close.
Building a Majority Node Set Cluster
Now that the Failover Clustering feature has been installed, it is time to create
the cluster. Once again, you will be creating a Majority Node Set Cluster
consisting of three cluster nodes. It is only necessary to perform the procedure
below on a single cluster node. To create the cluster, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, click on the Create Cluster link,
found in the Actions pane. When you do, Windows will launch the Create
Cluster Wizard.
4. Click Next to bypass the wizard’s Welcome screen.
5. Specify the names of the servers that you want to include in the cluster
(Figure 2.19).
46
Understanding Hyper-V in Windows Server 2012
Figure 2.19
Specify the names of the servers that will make up the cluster.
6. Click Next.
7. You should now see a message indicating that the cluster has not yet
been validated. Choose the option to run the validation tests and click
Next (Figure 2.20). This will cause Windows to launch the Validate
a Cluster Wizard.
Figure 2.20
The cluster must be validated.
47
Understanding Hyper-V in Windows Server 2012
8. Click Next to bypass the wizard’s Welcome screen.
9. Choose the Run All Tests (Recommended) option and click Next
(Figure 2.21).
Figure 2.21
You must run all of the validation tests.
10. Click Next to begin the validation tests.
11. When the validation tests complete, take a moment to view the report
and review any errors or warnings (Figure 2.22). Click Finish.
48
Understanding Hyper-V in Windows Server 2012
Figure 2.22
Review the validation report for any errors or warnings.
12. When prompted, enter a name for the cluster and assign an IP address
to the cluster (Figure 2.23). The name and IP address that you use should
be unique and will be used to identify the cluster as a whole.
Figure 2.23
Specify the name and IP address to be used by the cluster.
49
Understanding Hyper-V in Windows Server 2012
13. Click Next.
14. Take a moment to verify the information presented on the confirmation
screen and click Next.
15. You should now see a message indicating that the cluster was created
successfully (Figure 2.24). Click Finish to close the wizard.
Figure 2.24
Verify that the cluster has been created successfully.
Shared storage
In the past if you wanted to use failover clustering with Hyper-V, you had to
make use of shared storage in the form of a Cluster Shared Volume. Although
Hyper-V 3.0 does not require a Cluster Shared Volume for clustering, shared
storage is still the preferred method for building a failover cluster.
As has always been the case, you can create a Cluster Shared Volume on
virtually any iSCSI or Fibre Channel accessible storage device. This can include
a SAN, a physical NAS appliance or even a server that is configured to act as
a shared storage device. The actual method you use to provision the shared
storage varies depending on the physical hardware you are using.
For the sake of demonstration, this example will use a Windows Server to
host the shared storage and will connect to this server using iSCSI. This server
contains four physical hard disks. The first hard disk is a 250-GB disk that
contains the Windows Server 2012 operating system files. The remaining
three hard disks are each 500 GB in size and will be configured to act as
a RAID 5 array. Keep in mind that this configuration is only being used for
demonstration purposes. Real-world organizations typically use larger arrays
and those arrays are often configured as RAID 6 or as RAID 10, because
such RAID configurations are resistant to the failures of multiple drives.
For this demonstration, however, RAID 5 will work within the limitations of
the lab hardware.
50
Understanding Hyper-V in Windows Server 2012
There are two ways to create the necessary storage array. The legacy method,
which will be discussed first, is the one you will have to use this method if
your shared storage resides on an older version of Windows Server. The other
method is the preferred method of storage provisioning in Windows Server
2012, which will be discussed second.
Legacy storage provisioning
The first technique describes how to create a storage array using the Windows
Disk Management Console. You will have to use if you are hosting the storage
on an older version of Windows Server. This method works for Windows
Server 2012 as well, but Microsoft prefers that you use a newer method called
Storage Spaces.
To use the Disk Management Console to create a RAID 5 array, follow
these steps:
1. G
o to the server’s Run prompt and enter the DISKMGMT.MSC command.
This will cause Windows to open the Disk Management Console
(Figure 2.25). Notice in the figure that Disk 1, Disk 2 and Disk 3 are of
equal size; all are online and contain no partitions. If you need to bring
a disk online, right-click on the disk and choose the Online command from
the right-click menu.
Figure 2.25
The Disk Management Console lists all of the server’s physical disks.
51
Understanding Hyper-V in Windows Server 2012
2. Right-click on one of the empty disks and choose the New RAID 5 volume
command from the right-click menu (Figure 2.26). Windows will launch
the New RAID 5 Volume Wizard.
Figure 2.26
Choose the New RAID-5 Volume command.
3. Click Next to bypass the wizard’s Welcome screen.
4. Select the disk that you wish to add to the volume and click Add
(Figure 2.27). Repeat this step for any additional disks that you wish to add
to the new RAID 5 volume.
Figure 2.27
Add the physical disks to the RAID 5 volume.
52
Understanding Hyper-V in Windows Server 2012
5. Click Next.
6. Select the drive letter that you wish to assign to the volume that you are
creating (Figure 2.28).
Figure 2.28
Assign a drive letter to the volume that you are creating.
7. Click Next.
8. On the following screen choose the file system that you wish to use on the
new volume and decide whether to perform a quick format (Figure 2.29).
Figure 2.29
Choose a file system and format the new volume.
53
Understanding Hyper-V in Windows Server 2012
9. Click Next.
10. Click Finish.
11. A warning message tells you that the operation will convert the basic disks
to dynamic disks (Figure 2.30). Click Yes to continue.
Figure 2.30
The disks used in the array will be converted to dynamic disks.
12. After a brief delay Windows will format and synchronize the new volume.
Depending on the size of the disks that you are using, the synchronization
process can take a considerable amount of time to complete.
13. When the synchronization process completes, the new volume should be
displayed as Healthy (Figure 2.31).
Figure 2.31
The new volume should eventually be listed as healthy.
54
Understanding Hyper-V in Windows Server 2012
Using Windows Storage Spaces
As previously mentioned, using the Disk Management Console to provision
a storage array will work in Windows Server 2012, but that method is primarily
suited for volumes that are stored on legacy versions of Windows Server. If
a storage volume is stored on Windows Server 2012, Microsoft recommends
using a new feature called Windows Storage Spaces. The main benefits to using
Windows Storage Spaces instead of the Disk Management Console include:
• Volumes created using Windows Storage Spaces can be thin provisioned.
• You can add additional physical disk space as needed.
• You can choose the type of redundancy that is most beneficial.
• Storage resources can be provisioned much more quickly than they can
through the Disk Management Console.
Creating a storage pool
The first step in the process of configuring Windows Storage Spaces is to create
a storage pool. A storage pool is a collection of physical disks that act as a pool
of storage resources. You can create a storage pool by completing these steps:
1. Open the Server Manager.
2. Click on the File and Storage Services option, found in the console tree.
3. Click on Disks to verify that all of the server’s disks are displayed within
the console (Figure 2.32).
Figure 2.32
Click on the Disks container.
4. Click on Storage Pools (Figure 2.33).
55
Understanding Hyper-V in Windows Server 2012
Figure 2.33
The Primordial pool is created by default, but you will have to manually create all other
storage pools.
5. Choose the New Storage Pool option from the Task list.
6. When the New Storage Pool Wizard begins, click Next to bypass
the wizard’s Welcome screen.
7. Enter a name and an optional description of the storage pool that you
are creating.
8. Click Next.
9. Choose the disks that you wish to include within the storage pool
(Figure 2.34).
Figure 2.34
Choose the disks that you wish to include in the storage pool.
56
Understanding Hyper-V in Windows Server 2012
10. Use the Allocation drop down for each disk to control whether the disk
should be allocated as a data store, a hot spare, or a manual allocation
(Figure 2.35).
Figure 2.35
Specify the allocation for each disk in the storage pool.
11. Click Next.
12. Click Create.
13. When the storage pool has been created, click Close (Figure 2.36).
Figure 2.36
Verify that the storage pool has been created successfully.
57
Understanding Hyper-V in Windows Server 2012
You should now see the storage pool listed in the console along with
the physical disks that make up the storage pool (Figure 2.37).
Figure 2.37
The completed storage pool should look like this.
Creating a virtual disk
After the storage pool is created, the next step is to create a virtual disk within
the storage pool. This virtual disk will act as a repository for the virtual machine
components that will be stored within the Cluster Shared Volume. To create
the virtual disk, follow these steps:
1. Open the Server Manager if it is not already open.
2. Click on the File and Storage Services option, found in the console tree.
3. Click on the To Create a Virtual Disk, Start the New Virtual Disk
Wizard link.
4. When the New Virtual Disk Wizard starts, click Next to bypass
the Welcome screen.
5. Select your storage pool from the list and click Next (Figure 2.38).
58
Understanding Hyper-V in Windows Server 2012
Figure 2.38
Select your storage pool and click Next.
6. Enter a name and an optional description for the virtual disk.
7. Click Next.
8. Choose whether you want to configure a simple virtual disk or have
the virtual disk be mirrored or use parity (Figure 2.39).
Figure 2.39
Choose the method Windows will use to protect your virtual disk.
59
Understanding Hyper-V in Windows Server 2012
9. Click Next.
10. Choose whether you want to thinly provision the Virtual Hard Disk or
create a disk of a fixed size (Figure 2.40). Fixed size provisioning delivers
better performance, but thin provisioning is more flexible and makes more
efficient use of storage space.
Figure 2.40
Choose the provisioning type.
11. Enter the size of the Virtual Hard Disk that you want to create (Figure 2.41).
60
Understanding Hyper-V in Windows Server 2012
Figure 2.41
Specify the size of your Virtual Hard Disk.
12. Click Next.
13. Take a moment to verify the information that is displayed on
the confirmation screen and click Create.
14. After you have created the virtual disk, click Close.
15. Windows will automatically launch the New Volume wizards. Click Next to
bypass the wizard’s Welcome screen.
16. When prompted, select your storage pool and the virtual disk that you
have created.
17. Click Next.
18. Specify the size of the volume and click Next.
19. Assign a drive letter to the volume and click Next.
20. Choose the file system that you want to use on the volume and click Next.
21. Verify the information displayed on the confirmation screen
and click Create.
22. When the volume has been created, click Close (Figure 2.42).
61
Understanding Hyper-V in Windows Server 2012
Figure 2.42
Verify that the virtual disk has been created successfully.
Building an iSCSI target
As previously mentioned, Cluster Shared Volumes are normally accessed either
through iSCSI or through Fibre Channel. For the sake of demonstration, this
section will show you how to create an iSCSI target for the recently created
storage volume.
Microsoft supported configuring Windows Server 2008 R2 as an iSCSI target,
but doing so required you to download an additional component. In Windows
Server 2012, the iSCSI target software is built into the operating system,
so there is nothing extra to download.
Starting the iSCSI Initiator
Before you begin configuring the iSCSI target, it is helpful to start the iSCSI
Initiator on each of the cluster nodes. The reason for doing this now is that
each of the cluster nodes will be assigned an iSCSI Qualified Name (IQN). You
will need to provide each node’s IQN when you configure the iSCSI target. To
start each node’s iSCSI Initiator, complete these steps:
1. Open the Server Manager.
2. Choose the iSCSI Initiator command from the Tools menu
3. You should see a message indicating that the Microsoft iSCSI Service is not
running. Click Yes to start the service.
4. When the iSCSI Initiator launches, go to the properties sheet’s
Configuration tab and note the Initiator Name (Figure 2.43).
5. Repeat these steps for each cluster node.
62
Understanding Hyper-V in Windows Server 2012
Figure 2.43
Note the IQN for each cluster node.
Installing the iSCSI target software
Although Windows Server 2012 includes the iSCSI target software, it is not
installed by default. To deploy the iSCSI target software onto the server that
will host your Cluster Shared Volume, follow these steps:
1. Open the Server Manager.
2. Choose the Add Roles and Features command from the Manage menu.
3. When the Add Roles and Features Wizard launches, click Next to bypass
the wizard’s Welcome screen.
4. On the Select Installation Type screen, choose the Role‑Based
or Feature‑Based Installation option (Figure 2.44).
63
Understanding Hyper-V in Windows Server 2012
Figure 2.44
Choose the Role-Based or Feature-Based Installation option.
5. Click Next.
6. Verify that the server that will host the Cluster Shared Volume is selected
(Figure 2.45).
Figure 2.45
Make sure that the server that will host the iSCSI target is selected.
64
Understanding Hyper-V in Windows Server 2012
7. Click Next.
8. On the Select Server Roles screen, verify that the File and Storage
Services role is installed. This role should be installed by default.
9. Expand the File and Storage Services container.
10. Expand the File and iSCSI Services container (Figure 2.46).
11. Select the iSCSI Target Server option and the iSCSI Target Storage
Provider option. If you are prompted to add additional features to support
those services, click the Add Features button.
Figure 2.46
Select the iSCSI Target Software and the iSCSI Target Storage Provider components.
12. Click Next.
13. Click Next on the Select Features screen (it is not necessary to deploy
any additional features at this time).
14. When you reach the confirmation screen, click Install (Figure 2.47).
65
Understanding Hyper-V in Windows Server 2012
Figure 2.47
Click Install to install the iSCSI Target software.
15. When the installation completes, click Close.
Configuring the iSCSI target
Now that you have installed the iSCSI target software, you need to configure it.
This means creating an iSCSI virtual disk (within the virtual disk that was already
created in Windows Storage Spaces). You will also need to provide the iSCSI
target with an authentication method as well as the IQNs of the cluster nodes.
To configure the iSCSI target software, follow these steps:
1. Open the Server Manager if it is not already open.
2. Click on the File and Storage Services option, found in the console tree.
3. Click on iSCSI.
4. Click the To Create an iSCSI Virtual Disk, Start the New iSCSI Virtual Disk
Wizard link (Figure 2.48).
Figure 2.48
Click the To Create an iSCSI Virtual Disk, Start the New iSCSI Virtual Disk Wizard link.
66
Understanding Hyper-V in Windows Server 2012
5. When the New iSCSI Virtual Disk Wizard begins, select your storage pool
and the volume that you just created (Figure 2.49).
Figure 2.49
Select the volume that you just created.
6. Click Next.
7. Specify a name and an optional description for the iSCSI virtual disk
and click Next.
8. Specify a size for the iSCSI virtual disk and click Next.
9. Choose the New iSCSI Target option and click Next.
10. Enter a name and an optional description for the iSCSI target and click
Next.
11. Add the names of the iSCSI initiators that will access the target. Populate
the dialog box with the IQN names from the iSCSI initiators on all of your
cluster nodes (Figure 2.50).
67
Understanding Hyper-V in Windows Server 2012
Figure 2.50
You must provide the IQNs of your iSCSI initiators.
12. Once all of the cluster nodes have been added to the list, click Next.
13. Although not technically required, authentication is important for iSCSI
connectivity. Otherwise someone could easily spoof an IQN and gain
access to your iSCSI target. The wizard gives you a choice of enabling
CHAP or reverse CHAP authentication. As a best practice, you should
enable CHAP and provide a strong name and password (Figure 2.51).
Please note that your password must be at least 12 characters in length.
68
Understanding Hyper-V in Windows Server 2012
Figure 2.51
It is a good idea to use CHAP authentication for your iSCSI target.
14. Click Next.
15. Verify the information shown in the confirmation screen, and click Create
(Figure 2.52).
Figure 2.52
Take a moment to identify the iSCSI target configuration information.
16. When the process completes, click Close.
69
Understanding Hyper-V in Windows Server 2012
Attaching the cluster nodes to the iSCSI storage
Now that you have created the iSCSI target and authorized the individual
cluster nodes to use the target, it is time to attach the cluster nodes to the
iSCSI target. You can do so by performing the following procedure on each
cluster node:
1. Open the Server Manager.
2. Choose the iSCSI Initiator from the Tools menu.
3. When the iSCSI Initiator opens, go to the Targets tab.
4. Enter the IP address of the server that is hosting the iSCSI target in
the Target field.
5. Click the Quick Connect button.
6. You should see your iSCSI target listed as inactive (Figure 2.53). Select
the iSCSI target and click Done.
Figure 2.53
Your iSCSI target should be listed as inactive.
70
Understanding Hyper-V in Windows Server 2012
7. You should now be returned to the main initiator screen with the Targets
tab selected (Figure 2.54).
Figure 2.54
Your target should be listed on the Targets tab.
8. Select the target, which should be listed as inactive, and click
the Connect button.
9. Verify that the target name is correct and that the Add this Connection to
the List of Favorite Targets option is selected (Figure 2.55).
71
Understanding Hyper-V in Windows Server 2012
Figure 2.55
You must add the target to the list of favorite targets and enable multi-path.
10. Select the Enable Multi-Path check box. This is a critical step because
you won’t be able to create a Cluster Shared Volume unless this option
is selected.
11. Click the Advanced button.
12. When the Advanced Settings dialog box launches, select the Enable
CHAP Log On check box (Figure 2.56).
Figure 2.56
You must choose the Enable CHAP Log On option and enter your CHAP credentials.
72
Understanding Hyper-V in Windows Server 2012
13. Enter the name that you specified earlier. You should enter the CHAP
password into the Target Secret field.
14. Click OK.
15. Click OK.
16. When you are returned to the Targets tab, the iSCSI Target should be
listed as Connected.
17. Click OK to close the iSCSI Initiator Properties sheet.
18. Repeat this procedure on the remaining cluster nodes so that each cluster
node has iSCSI connectivity to the target.
Making storage available to the cluster
Now that you have connected each cluster node to the iSCSI target, you must
prepare the iSCSI storage for use by the cluster. This means creating the volume
and configuring the cluster to recognize the shared storage. To do so, follow
these steps:
1. Enter the DISKMGMT.MSC command to open the Disk Management
Console.
2. When the Disk Management Console opens, locate the iSCSI volume.
3. Right-click on the disk associated with the iSCSI target and choose
the Online command from the right-click menu (Figure 2.57).
Figure 2.57
You must bring the Cluster Shared Volume online.
4. Right-click on the disk associated with the iSCSI target and choose
the Initialize Disk command from the right-click menu.
5. When prompted, select the type of partition that you wish to use with
the disk (Figure 2.58) and click OK.
73
Understanding Hyper-V in Windows Server 2012
Figure 2.58
Select the type of partition that you wish to use for your Cluster Shared Volume and click OK.
6. Right-click on the unallocated space and create a volume. Do not assign
a drive letter to the volume.
7. Close the Disk Management Console.
8. Open the Server Manager.
9. Choose the Failover Cluster Manager option from the Tools menu.
10. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster name> | Storage | Disks
(Figure 2.59).
Figure 2.59
Navigate through the Failover Cluster Manager to Failover Cluster Manager | <your cluster
name> | Storage | Disks.
11. Click the Add Disk link, found in the Actions pane.
12. The Failover Cluster Manager should automatically recognize your iSCSI
Target as a disk that can be added to the cluster (Figure 2.60). Verify that
the disk is selected and click OK.
74
Understanding Hyper-V in Windows Server 2012
Figure 2.60
Select the Custer Shared Volume and click OK.
13. The Failover Cluster Manager should list the disk as being available to
the cluster and show the disk status as Online (Figure 2.61). It is worth
noting that it can occasionally take a minute or two for the disk status to
be updated.
Figure 2.61
The Cluster Shared Volume should be listed within the Failover Cluster Manager.
14. With the cluster disk selected, click Add to Cluster Shared Volumes.
Installing the Hyper-V role
The next step in the process is to install the Hyper-V role. You must install this
role into each of the cluster nodes. You can complete this process by following
these steps:
1. Open the Server Manager.
2. Choose the Add Roles and Features command from the Manage menu.
3. When the Add Roles and Features wizard launches, click Next to bypass
the wizard’s Welcome screen.
75
Understanding Hyper-V in Windows Server 2012
4. Make sure that the Role-Based or Feature-Based Installation option is
selected and click Next.
5. Select the server on which you want to deploy the Hyper-V role and click
Next.
6. Select the Hyper-V option from the list of roles.
7. If you are prompted to add additional features, click the Add Features
button.
8. Click Next.
9. Click Next.
10. Click Next.
11. Select the network adapters that you want to connect to the virtual switch
(Figure 2.62). You can select multiple network adapters, but as a best
practice you should reserve a network adapter for management traffic
and you should reserve an adapter for cluster communications (such as
cluster heartbeats and live migration traffic).
Figure 2.62
Select the network adapters to be used by Hyper-V.
12. Click Next.
13. Select the checkbox for Allow this Server to Send and Receive Live
Migrations of Virtual Machines (Figure 2.63).
76
Understanding Hyper-V in Windows Server 2012
Figure 2.63
Your cluster nodes must be able to live migrate virtual machines.
14. Select the authentication protocol to be used by live migration traffic.
If the cluster nodes reside in the same Active Directory domain as one
another then you should use the Kerberos protocol. Kerberos is more
secure than CredSSP and the configuration process is easier.
15. Click Next.
16. Click Next to accept the default store location.
17. Take a moment to verify the information that is displayed on
the Confirmation screen and then click Install.
18. When the installation process completes, click Close and then reboot
the server.
19. Repeat these steps for each node in the cluster.
Making Hyper-V fault tolerant
Now that you have installed the Hyper-V role, the next step in the process is
to make Hyper-V and your virtual machines fault tolerant. The simple act of
creating a virtual machine does not make the virtual machine fault tolerant.
You must create the virtual machine in the correct location and you will have to
designate the virtual machine as being fault tolerant.
When you create a new virtual machine, the New Virtual Machine Wizard asks
if you want to store the virtual machine in a different location (see Chapter 6
for details). If you want the virtual machine to be fault tolerant, you must store
the virtual machine on the Cluster Shared Volume.
77
Understanding Hyper-V in Windows Server 2012
As you may recall, you created a volume on the iSCSI target, but did not
assign a drive letter to it. You can access the Cluster Shared Volume at C:\
ClusterStorage\<your volume name>. Anything that you save to this path will
reside on the Cluster Shared Volume (the iSCSI target) rather than on the local
C: drive.
Simply storing the virtual machines on the Cluster Shared Volume is not
enough (Figure 2.64). As you can see in the figure, three virtual machines have
been created, and each of these virtual machines resides on the Cluster Shared
Volume. If you look at the lower middle pane in the next figure, however, you
will notice that the Hyper-V Manager indicates that the virtual machine is not
clustered (Figure 2.65).
Figure 2.64
Virtual machines must be stored on the Cluster Shared Volume.
78
Understanding Hyper-V in Windows Server 2012
Figure 2.65
Even with the virtual machines residing on the Cluster Shared Volume, the virtual machines
are not considered to be fault tolerant.
To make the virtual machine fault tolerant you must designate it as such
through the Failover Cluster Manager. To do so, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager from the list of tools.
3. When the Failover Cluster Manager opens, navigate through the
console tree to Failover Cluster Manager | <your cluster name> | Roles
(Figure 2.66).
Figure 2.66
Navigate through the Failover Cluster Manager to Failover Cluster Manager | <your cluster
name> | Roles.
79
Understanding Hyper-V in Windows Server 2012
4. Click the Configure Role link, found in the Actions pane.
5. Windows will now launch the High Availability Wizard. Click Next to
bypass the wizard’s Welcome screen.
6. The next screen lists a variety of server roles. Select the Virtual Machine
role from the list and click Next (Figure 2.67).
Figure 2.67
Select the Virtual Machines option.
7. Select the virtual machines that you wish to make fault tolerant and click
Next (Figure 2.68).
80
Understanding Hyper-V in Windows Server 2012
Figure 2.68
Select the virtual machines that you wish to make fault tolerant.
8. Verify the information displayed on the confirmation screen and click
Next.
9. When the process completes you should see a message confirming that
high availability was successfully configured (Figure 2.69). Click the View
Report button to examine the report. Click Finish.
Figure 2.69
Click the View Report button to see a report of the operation.
81
Understanding Hyper-V in Windows Server 2012
After the virtual machines become fault tolerant, you should see them listed
in the Failover Cluster Manager’s Roles container (Figure 2.70). Likewise,
the Hyper-V Manager should list the virtual machine as being clustered
(Figure 2.71).
Figure 2.70
The Failover Cluster Manager now displays the virtual machines.
82
Understanding Hyper-V in Windows Server 2012
Figure 2.71
The Hyper-V Manager lists the virtual machines as being clustered.
Using SMB storage
This chapter has focused primarily on the use of local, direct attached storage
and on connecting to a Cluster Shared Volume through iSCSI. However, those
are not your only options. Hyper-V is also able to store virtual machines on an
SMB file share in both clustered and non-clustered environments.
The use of SMB storage is generally only practical for smaller organizations
because bandwidth limitations impact the number of virtual machines that can
reside on a file share. The use of SMB file share storage for virtual machines is
most useful when a file server has been configured to be highly available.
Finally, storing virtual machines on SMB file shares is only an option if
the servers involved are using SMB version 2.2 or higher. Earlier versions of
SMB are not supported.
83
Understanding Hyper-V in Windows Server 2012
Chapter 3
Migrations
In the previous chapter, you spent a lot of time building
failover clusters and making virtual machines fault tolerant.
However, building the cluster is really just the beginning.
It is equally important to know how to verify that
your failover cluster is working properly. As a Hyper-V
administrator, you will also need to know how to move
virtual machines around both within and outside of
the cluster. This chapter discusses all of these tasks.
84
Understanding Hyper-V in Windows Server 2012
Testing failover clustering
One of the nice things about building a failover cluster is that you have
the assurance that if any of your cluster nodes were to fail, the virtual machines
that had been running on the failed node will automatically fail over to a node
that is still functioning. Of course this raises the question of how you can test
virtual machine failover. Simply shutting down a cluster node is an inadequate
test because a graceful shutdown is not as abrupt as an unexpected node
failure. At the same time, however, you don’t want to be yanking the power
cord out of a cluster node to see what would happen in the event of
a real failure.
The ability to test virtual machine failover was something that was sorely
lacking from Hyper-V 2.0. Thankfully, Microsoft has included a testing feature
in Hyper-V 3.0.
Live migrating a VM within the cluster
Although a failover cluster is designed to automatically move a virtual machine
to a functioning cluster node in the event of a failure, you may occasionally
want to move a virtual machine to another cluster node even if no failure has
occurred. For example, if you are planning to take a cluster node down for
maintenance then you would probably want to move the virtual machines to
another node before doing so. Likewise, if you determine that a single cluster
node is handling a disproportionate amount of the cluster’s total workload, you
might decide to move some of the virtual machines to another node.
Performing a live migration within a cluster is simple. To do so, complete
these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your Cluster> | Roles.
4. Right-click on the virtual machine that you want to live migrate and select
the Move | Live Migration | Select Node commands from the right-click
menus (Figure 3.1). As an alternative, you can allow Hyper-V to select
the destination cluster node by choosing the Best Possible Node option.
85
Understanding Hyper-V in Windows Server 2012
Figure 3.1
You can select the destination node manually, or you can let Hyper-V pick the best
node automatically.
5. Choose the cluster node to which you want to live migrate the virtual
machine (Figure 3.2).
Figure 3.2
Select the cluster node to which you want to live migrate the virtual machine.
6. Click OK.
7. You can monitor the live migration process through the Failover Cluster
Manager (Figure 3.3).
86
Understanding Hyper-V in Windows Server 2012
Figure 3.3
The Failover Cluster Manager displays the progress of the live migration.
8. When the live migration completes, the Failover Cluster Manager should
report the virtual machine as running on the cluster node that you have
selected (as shown in the Owner Node column) (Figure 3.4).
Figure 3.4
The Owner Node column confirms that the virtual machine has been moved to a different
cluster node.
Configuring a server to send and receive
live migrations
Hyper-V doesn’t limit you to performing virtual machine migrations within
the confines of a cluster. You can also perform live migrations between
standalone Hyper-V hosts or even between Hyper-V clusters, but the hosts
involved must be configured to allow live migrations.
If you followed the instructions from the previous chapter, your cluster should
be capable of live migrating virtual machines within a cluster. However, if you
have a standalone Hyper-V host that was not initially configured to allow live
migrations, that host will need to be reconfigured prior to using it in any live
migration scenario. To configure a Hyper-V Host to allow live migrations, follow
these steps:
1. Open the Hyper-V Manager.
2. Right-click on your host server and choose the Hyper-V Settings
command from the right-click menu (Figure 3.5).
87
Understanding Hyper-V in Windows Server 2012
Figure 3.5
Right-click on the listing for the host server and select the Hyper-V Settings command from
the right-click menu.
3. When the Hyper-V Settings dialog box launches, select the Live
Migrations option (Figure 3.6).
Figure 3.6
Select the Live Migrations tab.
88
Understanding Hyper-V in Windows Server 2012
4. Select the Enable Incoming and Outgoing Live Migrations check box
(Figure 3.7).
Figure 3.7
You must manually enable incoming and outgoing live migrations.
5. Specify the authentication protocol to use. Kerberos is the preferred
authentication protocol because it is more secure and the configuration
process is easier, but it only works within a common Active
Directory forest.
6. Specify the maximum number of simultaneous live migrations to allow.
7. Specify the IP addresses for the NICs with which the server is authorized
to live migrate virtual machines. You can select the Use Any Available
Network for Live Migration option, but this is less secure than the Use
These IP Addresses for Live Migration option.
8. Click OK to complete the process.
Dealing with CPU mismatch
If you plan to live migrate virtual machines between Hyper-V hosts, it is best
to use identical hardware on all of your cluster nodes if possible. Of course
acquiring identical hardware is not always possible. The next best thing
is to use servers with identical CPUs. If you attempt to live migrate virtual
machines between servers with dissimilar CPUs you will receive an error
message indicating that the virtual machine is using processor-specific features
and cannot be migrated (Figure 3.8).
89
Understanding Hyper-V in Windows Server 2012
Figure 3.8
You will receive an error message if the CPUs on the source and destination hosts are
too dissimilar.
The solution to this problem is to enable CPU compatibility. You can accomplish
this by following these steps:
1. Open the Hyper-V Manager.
2. Shut down the virtual machine.
3. Right-click on the virtual machine and choose the Settings command from
the right-click menu.
4. Expand the Processor container in the resulting dialog box.
5. Select the Compatibility container.
6. Select the checkbox for Migrate to a Physical Computer with a Different
Processor Version (Figure 3.9).
7. Click OK.
8. Restart the virtual machine.
9. Attempt the live migration.
90
Understanding Hyper-V in Windows Server 2012
Figure 3.9
You can overcome some live migration issues by enabling the processor compatibility feature.
It is worth noting that enabling the CPU compatibility feature does not allow
you to move virtual machines between hosts with different CPU architectures
(e.g., moving from a host with an Intel processor to a host with an AMD
processor). Furthermore, enabling CPU compatibility might impact the virtual
machine’s performance because the feature works by disabling the virtual
machine’s access to some of the more advanced CPU features such as
Misaligned SSE or POPCNT.
Live migrations beyond the cluster
One of the really interesting things that Microsoft has done in Hyper-V 3.0 is
to make it possible to live migrate virtual machines from one host to another
regardless of whether or not the host servers are clustered. In Hyper-V 3.0 you
can perform the following types of migrations:
• Cluster node → cluster node
• Cluster node → standalone host
• Standalone host → cluster node
• Standalone host → standalone host
For the most part, Microsoft offers these types of migrations as a convenience
feature. For example, suppose that you have a non-clustered Hyper-V
server that is running your production virtual machines. Now suppose
that you purchase some new servers and build a Hyper-V cluster. In that
type of situation it is possible to use live migration to move running virtual
machines from the standalone server onto a cluster node. After doing so,
you can configure the Failover Cluster Manager to make the virtual machines
fault tolerant.
91
Understanding Hyper-V in Windows Server 2012
Although it is easy to think of live migrations as a clustering feature, Hyper-V
makes it possible to live migrate virtual machines even if the host servers that
are involved in the migration process are not clustered.
Live migrating a VM to a server outside of the cluster
The first technique involves moving a clustered virtual machine to a non
clustered Hyper-V host. This procedure requires you to remove the virtual
machine’s fault tolerance as a part of the migration process.
Before you begin the migration process, choose the type of move that you
want to perform. Hyper-V gives you three different options including:
• Move the Virtual Machine’s Data to a Single Location – This option places
all of the virtual machine components into a single location.
• Move the Virtual Machine’s Data by Selecting Where to Move Each Item –
This option gives you the most flexibility because it allows you to control
where each virtual machine component will be placed. This is usually
the option that you will use when performing cluster-to-standalone
host migrations.
• Move Only the Virtual Machine – This option moves the virtual machine
itself to a new host, but leaves the Virtual Hard Disk in its original location
on the Cluster Shared Volume.
The steps below describe the procedure for moving a clustered virtual machine
to a Hyper-V host that exists outside of the cluster. This procedure assumes
that all of the host servers exist within a common domain and that you will be
specifying where to move the various virtual machine components. To perform
the virtual machine migration, follow these steps:
1. Open the Server Manager.
2. Select the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster> | Roles.
4. Select the virtual machine that you want to migrate away from the cluster.
5. Right-click on the virtual machine and select the Remove command from
the right-click menu (Figure 3.10).
92
Understanding Hyper-V in Windows Server 2012
Figure 3.10
Right-click on the virtual machine and select the Remove command from
the right‑click menu.
6. When you see the prompt asking if you want to remove the virtual
machine, click Yes (Figure 3.11).
Figure 3.11
Confirm that you want to remove the virtual machine from the cluster.
7. Close the Failover Cluster Manager.
8. Open the Hyper-V Manager.
9. Verify that the virtual machine is still running, and that it is not clustered
(Figure 3.12).
93
Understanding Hyper-V in Windows Server 2012
Figure 3.12
Make sure that the VM is still running and that it is no longer clustered.
10. Right-click on the virtual machine and choose the Move command from
the right-click menu.
11. When the Move Wizard starts, click Next to bypass the wizard’s
Welcome screen.
12. Choose the Move the Virtual Machine option and click Next (Figure 3.13).
94
Understanding Hyper-V in Windows Server 2012
Figure 3.13
Choose the option to move the virtual machine.
13. When prompted, enter the name of the destination host (Figure 3.14).
Figure 3.14
Specify the name of the destination host.
95
Understanding Hyper-V in Windows Server 2012
14. Click Next.
15. Choose the option to Move the Virtual Machine’s Data by selecting
Where to Move the Items (Figure 3.15).
Figure 3.15
Choose the option to move the virtual machine by selecting where to move each item.
16. Click Next.
17. Choose the option for moving the virtual machine’s components. It is
usually acceptable to choose the option to Move the Virtual Machine’s
Data Automatically (Figure 3.16). This option places the virtual machine
components in the same locations on the destination host as the locations
in which they resided on the source host.
96
Understanding Hyper-V in Windows Server 2012
Figure 3.16
It is usually acceptable to move the virtual machine’s data automatically.
18. Click Next.
19. Verify the information presented on the Summary screen.
20. Click Finish.
Live migrating an external VM into the cluster
If you have been using Hyper-V for a while, but are new to clustering, you
might encounter a situation in which you need to bring some production
virtual machines into a newly built cluster. Although you can use the Export /
Import method, it is usually easier to live migrate the virtual machines
from the standalone Hyper-V server into the cluster. This process involves
completing two main tasks: 1) migrate the virtual machine and 2) make
the virtual machine fault tolerant once it is running on a cluster node.
The procedure listed below assumes that the standalone Hyper-V host and all
of the cluster nodes belong to the same Active Directory domain and that
live migrations are enabled on all hosts. The procedure also assumes that
the cluster makes use of a Cluster Shared Volume. However, the procedure can
be easily adapted for environments without shared storage or for organizations
in which hosts reside in multiple domains. To perform the live migration,
complete the following steps:
1. Open the Hyper-V Manager on the standalone server that contains
the virtual machine that is to be migrated to the cluster.
2. Right-click on the virtual machine and choose the Move command from
the right-click menu.
97
Understanding Hyper-V in Windows Server 2012
3. When the Move Wizard opens, click Next to bypass the Welcome screen.
4. On the following screen, select the Move the Virtual Machine option and
click Next (Figure 3.17).
Figure 3.17
Select the Move the Virtual Machine option.
5. When prompted, enter the name of one of the cluster nodes (Figure 3.18).
Figure 3.18
Enter the name of the destination host.
98
Understanding Hyper-V in Windows Server 2012
6. Click Next.
7. Choose the Move the Virtual Machine’s Data to a Single Location option
(Figure 3.19).
Figure 3.19
Move the virtual machine to a single location.
8. Click Next.
9. Switch to the specified cluster node, open Windows Explorer and navigate
to C:\ClusterStorage\<volume name> (Figure 3.20).
99
Understanding Hyper-V in Windows Server 2012
Figure 3.20
Open Windows Explorer and navigate to your Cluster Shared Volume.
10. Create a folder matching the name of the virtual machine that is
to be migrated.
11. Switch back to the standalone host server where the virtual machine
currently resides.
12. Enter C:\ClusterStorage\<volume name>\<virtual machine name> as
the destination location folder (Figure 3.21).
Figure 3.21
Enter the path in which the virtual machine will be stored.
100
Understanding Hyper-V in Windows Server 2012
13. Verify that the destination folder has sufficient free disk space. The amount
of disk space required is listed in the Source Location portion of
the wizard’s current screen.
14. Click Next.
15. If the cluster node does not contain a virtual switch with a name matching
the virtual switch that is currently in use, you will be asked to specify
a virtual switch (Figure 3.22). Make your selection and click Next.
Figure 3.22
Specify the virtual switch that the virtual machine will use after the migration.
16. Verify the summary information and click Finish.
17. When the migration process completes, go to the destination cluster node
and verify that the virtual machine is running.
18. Switch to the destination cluster node and verify that the virtual machine is
present and running (Figure 3.23).
101
Understanding Hyper-V in Windows Server 2012
Figure 3.23
Verify that the virtual machine is running in its new location.
19. Open the Server Manager.
20. Choose the Failover Cluster Manager option from the Tools menu.
21. Navigate through the Failover Cluster Manager to Failover Cluster
Manager | <your cluster> | Roles.
22. Click on the Configure Roles link, found in the Actions pane.
23. When the High Availability Wizard launches, click Next to bypass
the Welcome screen.
24. Select the Virtual Machine option and click Next (Figure 3.24).
102
Understanding Hyper-V in Windows Server 2012
Figure 3.24
Select the Virtual Machine option from the list of high availability roles.
25. Select the recently migrated virtual machine from the list of virtual
machines and click Next (Figure 3.25).
Figure 3.25
Select the virtual machine that you want to make highly available.
103
Understanding Hyper-V in Windows Server 2012
26. Verify that the correct virtual machine is listed on the summary screen
and click Next.
27. Verify that the virtual machine was made highly available (Figure 3.26).
28. Click Finish.
Figure 3.26
You can use the report to verify the success of the operation.
Cluster-to-cluster live migrations
Just as you can live migrate virtual machines into and out of a cluster, you can
use a similar technique to live migrate a virtual machine between clusters.
When you do this, there will be a period of time during which the virtual
machine is not fault tolerant, but the virtual machine will remain online
throughout the migration process.
The technique described in this section assumes that all of the cluster nodes
exist within a common domain. It is also assumed that both clusters use shared
storage, although you can easily adapt the technique to a cluster that does not
use shared storage. To perform a cluster-to-cluster live migration, follow
these steps:
1. Open the Server Manager.
2. Select the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster> | Roles.
4. Select the virtual machine that you want to migrate to another cluster
(Figure 3.27).
104
Understanding Hyper-V in Windows Server 2012
Figure 3.27
Select the virtual machine that you want to move to another cluster.
5. Right-click on the virtual machine and select the Remove command from
the right-click menu.
6. When you see the prompt asking if you want to remove the virtual
machine, click Yes (Figure 3.28).
Figure 3.28
Click Yes to remove the virtual machine from the cluster.
7. Close the Failover Cluster Manager.
8. Open the Hyper-V Manager.
9. Verify that the virtual machine is still running, and that it is not clustered
(Figure 3.29).
Figure 3.29
Make sure that the VM is still running and that it has been removed from the cluster.
105
Understanding Hyper-V in Windows Server 2012
10. Right-click on the virtual machine and choose the Move command from
the right-click menu.
11. When the Move Wizard launches, click Next to bypass the wizard’s
Welcome screen.
12. Choose the option to Move the Virtual Machine (Figure 3.30)
and click Next.
Figure 3.30
Choose the Move the Virtual Machine option.
13. When prompted, enter the name of the destination host.
14. Click Next.
15. Choose the option to Move the Virtual Machine’s Data to a Single
Location (Figure 3.31).
106
Understanding Hyper-V in Windows Server 2012
Figure 3.31
Choose the option to move the virtual machine to a single location.
16. Click Next.
17. Switch to a node on the destination folder.
18. Open Windows Explorer and navigate to C:\ClusterStorage\
<volume name>
19. Create a folder bearing the name of the virtual machine that is to
be migrated.
20. Switch back to the cluster node where the virtual machine is
currently running.
21. Enter the path where the virtual machine will reside. The path should be
C:\ClusterStorage\<volume name>\<virtual machine name> (Figure 3.32).
107
Understanding Hyper-V in Windows Server 2012
Figure 3.32
Enter the path where the virtual machine should be stored on the destination cluster.
22. Verify that the destination folder has sufficient free disk space. The amount
of disk space required is listed in the Source Location portion of
the wizard’s current screen.
23. Click Next.
24. If the cluster node does not contain a virtual switch with a name matching
the virtual switch that is currently in use, you will be asked to specify
a virtual switch. Make your selection and click Next.
25. Verify the summary information and click Finish.
26. When the migration process completes, go to the destination cluster node
and verify that the virtual machine is running.
27. Switch to the destination cluster node and verify that the virtual machine is
present and running.
28. Open the Server Manager.
29. Choose the Failover Cluster Manager option from the Tools menu.
30. Navigate through the Failover Cluster Manager to Failover Cluster
Manager | <your cluster> | Roles.
31. Click on the Configure Roles link, found in the Actions pane.
32. When the High Availability Wizard launches, click Next to bypass
the Welcome screen.
33. Select the Virtual Machine option and click Next (Figure 3.33).
108
Understanding Hyper-V in Windows Server 2012
Figure 3.33
Select the Virtual Machine option from the list of roles that can be configured for
high availability.
34. Select the recently migrated virtual machine from the list of virtual
machines and click Next.
35. Verify that the correct virtual machine is listed on the summary screen
and click Next.
36. Verify that the virtual machine was made highly available.
37. Click Finish.
38. The virtual machine should now be displayed as a clustered resource
within the Failover Cluster Manager (Figure 3.34).
Figure 3.34
The virtual machine should be displayed within the Failover Cluster Manager.
109
Understanding Hyper-V in Windows Server 2012
Storage live migrations
Just as it is sometimes necessary to live migrate a virtual machine from one
Hyper-V host to another, it is also sometimes necessary to perform a storage
live migration. A storage live migration moves the virtual machine components
(Virtual Hard Disks, snapshots, etc.) from one storage location to another
without requiring the virtual machine itself to be moved to another host. This
is helpful when the volume containing virtual machine components is running
low on space or when the volume needs to be taken offline for maintenance.
As is the case with live migrations, storage live migrations can be performed
against a running virtual machine without causing a service interruption.
Storage migration within a cluster
The technique you use to perform a storage live migration varies depending
upon whether or not the virtual machine is fault tolerant. This section starts by
examining a technique for clustered environments. In this example, a virtual
machine is running on a Cluster Shared Volume and you will move the virtual
machine to an SMB volume. To perform this type of storage live migration,
complete the following steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. Navigate through the Failover Cluster Manager console to Failover Cluster
Manager | <your cluster> | Roles.
4. Right-click on the virtual machine on which you wish to perform a storage
migration and choose the Move | Virtual Machine Storage commands
from the right-click menus (Figure 3.35).
Figure 3.35
Right-click on a virtual machine and choose the Move | Virtual Machine Storage commands
from the right-click menu.
110
Understanding Hyper-V in Windows Server 2012
5. The Cluster Storage section is displayed in the lower left portion of
the Move Virtual Machine Storage window. If you have not previously
performed a storage live migration at the cluster level, this window
typically displays an error message stating that the network path was not
found. Right-click on this error and choose the Add Share command from
the right-click menu (Figure 3.36).
Figure 3.36
Right-click in the Cluster Storage section and choose the Add Share option.
6. When the Add a Network Share dialog box launches, enter the UNC share
name (\\servername\sharename) for the destination storage and click OK
(Figure 3.37).
Figure 3.37
Enter the path to the network share in UNC format.
7. Confirm that the Move Virtual Machine Storage dialog box lists
the specified network share in the Shares section (Figure 3.38).
111
Understanding Hyper-V in Windows Server 2012
Figure 3.38
Verify that the UNC path is displayed in the Shares section.
8. Drag the virtual machine from the top section of the dialog box to
the listing for the share that you have specified. The dialog box should
update to display the items that will be moved (Figure 3.39).
Figure 3.39
You should see the virtual machine components that are about to be migrated.
112
Understanding Hyper-V in Windows Server 2012
9. Click the Start button.
10. The Failover Cluster Manager should confirm that the storage migration
has begun (Figure 3.40). Although the virtual machine displayed in this
screen capture is powered off, the move could just as easily have been
performed while the virtual machine was running.
Figure 3.40
The Failover Cluster Manager should confirm that virtual machine migration has begun.
Storage migrations outside of a cluster
When it comes to performing storage migrations for non-clustered virtual
machines, you have three options: moving the entire virtual machine to a single
location, moving the virtual machine’s data to different locations or moving
only the Virtual Hard Disks. The sections below provide walkthroughs for all
three types of storage migrations.
Moving all of the virtual machine’s data to a single location
The first option is to move all of the virtual machine data to a single location.
This is the easiest of the storage live migration options and is likely to be
the option that you will use most often. To complete this type of storage live
migration, follow these steps:
1. Open the Hyper-V Manager.
2. Right-click on the virtual machine for which you wish to perform a storage
migration, and select the Move command from the right-click menu
(Figure 3.41).
Figure 3.41
Right-click on a VM and choose the Move command from the right-click menu.
113
Understanding Hyper-V in Windows Server 2012
3. When the Move wizard launches, click Next to bypass the wizard’s
Welcome screen.
4. Choose the option to move the virtual machine’s storage, and click Next
(Figure 3.42).
Figure 3.42
Choose the option to move the virtual machine’s storage.
5. Choose the option to Move All of the Virtual Machine’s Data to a Single
Location (Figure 3.43).
114
Understanding Hyper-V in Windows Server 2012
Figure 3.43
Choose the option to move all of the virtual machine’s data to a single location.
6. Click Next.
7. Specify the folder to which you want to move the virtual machine
(Figure 3.44). Pay attention to the Current Location section within
the wizard’s current screen. This section tells you how much physical disk
space the virtual machine is currently consuming. You must verify that
there is sufficient disk space in the new location.
115
Understanding Hyper-V in Windows Server 2012
Figure 3.44
Specify the path to which you want to move the virtual machine.
8. Click Next.
9. Verify the information shown on the Summary screen.
10. Click Finish.
Moving the virtual machine’s data to different locations
The second option for performing storage live migrations involves moving
virtual machine data to different locations. This option is useful for storage
migrations that require a bit more granular control. For instance, you can
use this option to place Virtual Hard Disk files in one storage location and
snapshot files in another. To perform this type of storage live migration, follow
these steps:
1. Open the Hyper-V Manager.
2. Right-click on the virtual machine for which you wish to perform a storage
migration and select the New command from the right-click menu.
3. When the Move wizard launches, click Next to bypass the wizard’s
Welcome screen.
4. Choose the option to move the virtual machine’s storage, and click Next.
5. Choose the option to Move the Virtual Machine’s Data to a Different
Locations (Figure 3.45).
116
Understanding Hyper-V in Windows Server 2012
Figure 3.45
Choose the option to move the virtual machine’s data to different locations.
6. Click Next.
7. Choose the virtual machine components that you want to move
(Figure 3.46) and click Next.
Figure 3.46
Select the virtual machine components that you want to move.
117
Understanding Hyper-V in Windows Server 2012
8. If you have chosen to move the Virtual Hard Disk, you will be prompted to
enter a new location for it (Figure 3.47). Enter the path to the Virtual Hard
Disk’s new location and click Next.
Figure 3.47
If prompted, enter a path in which to store the Virtual Hard Disk.
9. If you have chosen to move the virtual machine’s configuration, you will be
prompted to enter a path to the new location (Figure 3.48). Enter a path to
use for the virtual machine’s configuration and click Next.
118
Understanding Hyper-V in Windows Server 2012
Figure 3.48
Enter a path in which to store the virtual machine’s configuration.
10. If you have chosen to move the virtual machine snapshots, you will
be prompted to specify a path to the new location. Enter a path
and click Next.
11. If you have chosen to move the Smart Paging files, you will be prompted
to enter a new location for them (Figure 3.49). Enter a path for the smart
paging files and click Next.
119
Understanding Hyper-V in Windows Server 2012
Figure 3.49
Enter the path in which to store the smart paging file.
12. Verify the information on the summary screen and click Finish.
Moving only the Virtual Hard Drives
The third option for performing a storage migration is to move only the Virtual
Hard Disk files. This option is useful if you want to free up some storage
space by moving the virtual hard disk files, but want to keep the other virtual
machine components in their current location. You can complete this type of
storage live migration by following these steps:
1. Open the Hyper-V Manager.
2. Right-click on the virtual machine for which you wish to perform a storage
migration, and select the New command from the right-click menu.
3. When the Move wizard launches, click Next to bypass the wizard’s
Welcome screen.
4. Choose the option to move the virtual machine’s storage, and click Next.
5. Choose the option to Move Only the Virtual Machine’s Virtual Hard Disks
(Figure 3.50).
120
Understanding Hyper-V in Windows Server 2012
Figure 3.50
Choose the option to move only the virtual machine’s Virtual Hard Disks.
6. Click Next.
7. Select the Virtual Hard Disks that you want to move (Figure 3.51)
and click Next.
Figure 3.51
Select the Virtual Hard Disks that you wish to move.
121
Understanding Hyper-V in Windows Server 2012
8. Specify the location to which you wish to move the Virtual Hard Disks
and click Next (Figure 3.52).
9. Verify the information on the summary screen and click Finish.
Figure 3.52
Enter the path where the virtual hard disk should be stored.
122
Understanding Hyper-V in Windows Server 2012
Chapter 4
Managing Virtual
Machine Failover
The previous chapters show you how to build clustered
Hyper-V deployments and how to migrate virtual
machines within those environments. However, facilitating
live migrations is only part of a Hyper-V cluster’s job.
A cluster also has to keep virtual machines running, even
if the server on which a virtual machine is hosted were
to fail.
This chapter discusses various aspects of failover planning.
In this chapter you will learn about failover testing,
anti‑affinity rules and virtual machine prioritization.
123
Understanding Hyper-V in Windows Server 2012
Virtual machine failover
One of the big problems with server virtualization is that the virtualization
host (the Hyper-V server) can become a single point of failure that can impact
multiple virtual workloads.
In a physical datacenter, the failure of a single server is usually an inconvenience,
but it is rarely considered catastrophic. This isn’t necessarily the case in
a virtual datacenter.
In a virtual datacenter, a physical server running Hyper-V hosts has multiple
virtualized workloads. If this one, single physical server were to fail, all of the
virtual machines that are running on that server will fail as well – unless, of
course, the server is operating as a node within a failover cluster. Clustering is
what keeps virtual machines running, even if the physical hardware fails.
Failover testing
As you have no doubt seen in the previous chapters, there is a lot of work
that goes into building a Hyper-V cluster. However, none of the hard work
and expense means very much if your cluster fails to keep your virtual
machines running when a hardware failure occurs. Of course you probably
don’t want to wait for a disaster to happen in order to find out if your cluster
is working or not. It’s better to test the cluster ahead of time.
Failover cluster testing can be tricky in a production environment because
you don’t want to jeopardize your production virtual machines in the testing
process. And it’s never a good idea to test your clustering solution by walking
through the datacenter and randomly yanking power cords out of clustered
hosts. Even though this type of testing makes for an amusing story, it is hardly
a recommended method.
Microsoft gives you a few different methods of testing failover within your
cluster. However, all of these tests tend to focus on the cluster at a high level.
Microsoft does not provide a method for testing the failover of an individual
virtual machine.
Validation testing
The first type of testing that you can perform is a cluster validation test. If this
sounds familiar, it is probably because you performed a validation test when
you were preparing to build the failover cluster.
Even though you may think of a validation test as a tool to use in preparation
for building a cluster, you can perform these types of tests against a cluster
that has already been established. The reason why this might be helpful
is because cluster configurations tend to change over time and validation
testing will help you spot any configuration problems that might exist within
your cluster.
You can perform validation testing either through the Failover Cluster Manager
or through PowerShell. To perform validation testing using the Failover Cluster
Manager, follow these steps:
1. Open the Server Manager.
124
Understanding Hyper-V in Windows Server 2012
2. Select the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager opens, select the listing for your
cluster within the console tree.
4. Click on the Validate Cluster link, found in the Actions pane (Figure 4.1) .
Figure 4.1
Click on the Validate Cluster link.
5. When the Validate a Cluster Wizard begins, click Next to bypass
the wizard’s Welcome screen.
6. Choose the option to run only the tests that you select (Figure 4.2).
Figure 4.2
Choose the option to run only the tests that you select.
7. Click Next.
8. On the following screen, select the tests that you want to run (Figure 4.3).
You can select entire categories of tests (such as Inventory, Network, or
System Configuration), or you can expand a category and select individual
tests within that category.
125
Understanding Hyper-V in Windows Server 2012
Figure 4.3
Select the tests that you want to run.
9. Click Next.
10. The following screen displays your cluster disk (assuming that your cluster
uses a Cluster Shared Volume) and indicates that you can select the cluster
disk if you want to include it in the validation testing (Figure 4.4). However,
you should only run the tests against your cluster disk if the Cluster
Shared Volume has been stopped. Otherwise, the testing can cause virtual
machines to fail.
Figure 4.4
Do not select the cluster disk if your Cluster Shared Volume is in use!
126
Understanding Hyper-V in Windows Server 2012
11. Click Next.
12. Take a moment and look through the confirmation screen to make sure
that you have selected the proper tests.
13. Click Next to begin the tests.
14. When the tests complete, click the View Report button to view
the validation report (Figure 4.5).
15. Click Finish.
Figure 4.5
Click the View Report button to view the validation report.
Validation testing through PowerShell
Just as you can perform validation testing using the Failover Cluster Manager,
you can also validate clusters using PowerShell. PowerShell testing is very
flexible and you are free to pick and choose the tests that you want to run.
Validation testing with PowerShell is based on the Test-Cluster cmdlet. You can
perform comprehensive validation testing against all of your cluster nodes by
simply entering the Test-Cluster cmdlet (Figure 4.6). Keep in mind, however,
that you must not test Cluster Shared Volumes that are actively being used.
127
Understanding Hyper-V in Windows Server 2012
Figure 4.6
The Test-Cluster cmdlet can be used for comprehensive cluster validation testing.
When you first enter the Test-Cluster cmdlet, PowerShell may appear to
lock up. After several seconds you should see the tests begin, as shown in
Figure 4.6.
When the validation testing completes, you will see a message that refers to
a validation report (Figure 4.7). The validation report file is located in the C:\
Windows\Cluster\Reports folder. You can open the validation reports using
Internet Explorer, as shown in Figure 4.8.
Figure 4.7
The test’s output is written to a validation report.
Figure 4.8
Validation reports are displayed in Internet Explorer.
128
Understanding Hyper-V in Windows Server 2012
Keep in mind that the validation report shown in the figure above was based
on a comprehensive set of cluster tests. It is possible to exercise a high degree
of granular control over the testing process. Using PowerShell, you can run
specific validation tests, exclude certain validation tests and direct the testing
process to specific cluster nodes.
The trick to using PowerShell to control the validation tests is to retrieve a list
of the test names. Once you have a list of the test names (as referenced by
PowerShell) you can begin to include or exclude specific tests. To get a list of all
of the test names, enter the following command (Figure 4.9):
Test-Cluster – List
Figure 4.9
You can retrieve a list of all of the validation tests.
Once you have a list of test names, it is easy to include or exclude individual
tests. For example, suppose that you want to perform all of the validation tests
except for those related to storage. You can do so by entering the following
command:
Test-Cluster –Ignore Storage
Similarly, if you only want to run the system drivers test, you can enter
a command like this one (Figure 4.10):
Test-Cluster –Include “List System Drivers”
Figure 4.10
You can tell PowerShell to run specific tests.
129
Understanding Hyper-V in Windows Server 2012
You can also use PowerShell to specify the cluster nodes to include in
the validation tests. For example, suppose that you want to run the validation
tests against nodes named Lab1, Lab2, and Lab3 (Figure 4.11). To do so, you
can use the following command:
Test-Cluster –Node Lab1,Lab2,Lab3
Figure 4.11
You can run validation tests against individual cluster nodes.
Cluster resource testing
The second type of cluster testing you can perform is called cluster resource
testing. Cluster resource testing lets you see how your cluster would behave
if a specific resource failed. Unfortunately, this type of testing is somewhat
limited and there isn’t much documentation available from Microsoft
pertaining to it.
There are three important things that you need to know about cluster resource
testing prior to trying it:
1. Cluster resource testing simulates the failure of a cluster resource, so if you
do not perform the tests carefully you could cause an outage.
2. You can only test components that Microsoft defines as cluster resources.
You will find out how to get a list of these components below.
3. Often the name that Windows assigns to a cluster resource is different
from the name that you give to the resource. You can use cluster resource
testing to find out what would happen if a virtual machine fails, but you
won’t be able to reference the virtual machine by its usual name.
With that said, cluster resource testing is based on the use of the TestClusterResourceFailure cmdlet. The syntax for this cmdlet is simple. You only
have to specify the name of the resource that you want to test. The trick is
to figure out which resources are available for testing and the names that
Windows uses for those resources.
The easiest way to deal with this challenge is to enter the Get-ClusterResource
cmdlet. When you do this, PowerShell displays a list of the cluster resources
(Figure 4.12).
130
Understanding Hyper-V in Windows Server 2012
Figure 4.12
Use the Get-ClusterResource cmdlet to create a list of cluster resources.
Notice in the figure above that the last item on the list is Virtual Machine VM3.
This virtual machine’s name is VM3, but for the purpose of cluster resource
testing, the virtual machine must be referred to as Virtual Machine VM3. If
you want to see what would happen if the virtual machine fails, you can enter
the following command (Figure 4.13):
Test-ClusterResourceFailure “Virtual Machine VM3”
Figure 4.13
You can use PowerShell to simulate the failure of a virtual machine.
If you look at the Failover Cluster Manager, you can see that the virtual
machine can actually go down as a result of the test (Figure 4.14). Running
the test once against a virtual machine causes the virtual machine to go down
for a moment and then come back up. However, running the test twice usually
takes the virtual machine completely offline until you right-click on the virtual
machine and choose the Start option from the right-click menu.
Figure 4.14
Virtual machine failure testing takes the virtual machine offline.
131
Understanding Hyper-V in Windows Server 2012
For the most part, cluster resource failure testing is limited to the items on
the list of cluster resources (Figure 4.12). The big exception, however, is that you
can also test cluster disks. Suppose for example that you want to test the failure
of a disk named Cluster Disk 1 (Figure 4.12). You can do so by entering the
following command:
Test-ClusterResourceFailure –Name “Cluster Disk 1”
Figure 4.15
You can use the Test-ClusterResourceFailure cmdlet to test cluster disk failures.
Failover testing
The third type of testing you can do with regard to your cluster is failover
testing. Failover testing simulates the failure of an active cluster node and tests
the cluster’s ability to failover to another node in the cluster.
Unfortunately, Microsoft does not provide a mechanism for testing the failover
of an individual virtual machine. Instead, failover testing occurs at the cluster
level. To perform a failover test, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager appears, navigate through the console
tree to Failover Cluster Manager | <your cluster> (Figure 4.16) .
132
Understanding Hyper-V in Windows Server 2012
Figure 4.16
Select your cluster within the Failover Cluster Manager.
4. Click on the More Actions link, found in the Actions pane and then click
on the Simulate Failure link (Figure 4.17).
Figure 4.17
Click on the Simulate Failure option.
133
Understanding Hyper-V in Windows Server 2012
5. Windows will display a warning message telling you that simulating
afailure could cause clustered roles (in this case virtual machines) to be
moved to another cluster node, and that service could potentially be
interrupted. Click Yes to move forward with the test.
6. You can watch the failover happen in the Cluster Core Resources pane,
which is located in the lower, middle portion of the Failover Cluster
Manager (Figure 4.18).
Figure 4.18
You can watch the failover occur in the Cluster Core Resources pane.
Anti-affinity rules
In multi-tenant environments, it is sometimes necessary to configure certain
virtual machines so that they never reside on the same host server. For
example, if your organization were hosting virtual machines for both Coke
and Pepsi, you would not want the two companies’ virtual machines to reside
on a common host server.
It is relatively easy to keep virtual machines separate from one another when
you initially create the virtual machines. However, virtual machines are anything
but static and the chances of a virtual machine remaining on the same Hyper-V
host for an indefinite period of time are slim.
If you have virtual machines that need to be kept separate, you can reduce
the chances of those virtual machines ever ending up on a common host by
using anti-affinity rules. Anti-affinity rules prevent virtual machines that must
remain separate from failing over to a common host.
Unfortunately, anti-affinity rules are not exactly easy to work with. These
rules can only be established through PowerShell, and the process is not
very intuitive.
The key to understanding how the process works is to understand that
for every clustered virtual machine, there is a corresponding cluster group.
Each cluster group uses the same name as the virtual machine for which
it was created. Anti-affinity rules are applied to cluster groups, not to
virtual machines.
Like other types of objects in PowerShell, cluster groups have a number of
different properties (Figure 4.19). To see a list of the cluster group properties,
enter the following command:
Get-ClusterGroup <group name> | Select-Object *
134
Understanding Hyper-V in Windows Server 2012
Figure 4.19
Cluster groups are made up of a number of properties.
As you look at the properties in the screen capture above, you will notice that
the third property from the bottom of the list is named AntiAffinityClassNames.
Creating an anti-affinity rule involves assigning a value to this property.
Normally you could modify this type of value by using a command like this:
Get-ClusterGroup <virtual machine name> | Set-ClusterGroup –
AntiAffinityClassNames <value>
However, there is just one problem with the command shown above—there
is no Set-ClusterGroup cmdlet. The fact that such a command does not exist
is a safety precaution—if a Set-ClusterGroup cmdlet did exist, you could
potentially destroy a virtual machine if you used the cmdlet incorrectly.
Since you can’t use Get-ClusterGroup and Set-ClusterGroup, you have to use
a completely different approach to modifying the AntiAffinityClassNames
property.
Unfortunately, Windows PowerShell does not contain the code for managing
the AntiAffinityClassNames property. However, you can download a PowerShell
module that makes it possible to directly manipulate this property. In case
you are not familiar with the concept of a PowerShell module, it is basically
a collection of PowerShell cmdlets that can be bolted on to the core cmdlet set.
You can download the PowerShell Module for Configuring AntiAffinityClassNames
in Failover Clustering at: http://gallery.technet.microsoft.com/PowerShellmodule-for-16242485. This module is designed for use with Windows Server
2008 R2, but it works with Windows Server 2012 as well.
The download consists of a ZIP file. You will need to download the ZIP file
and extract its contents to the server’s hard disk. The path that you use is up to
you, but you will have to enter the full path into PowerShell, so it is beneficial
to use a relatively simple path. For demonstration purposes this example places
the extracted files into a folder named C:\Modules.
135
Understanding Hyper-V in Windows Server 2012
Once you have extracted the zip file’s contents, you’ll need to import
the module into PowerShell. Note that importing a module is not a permanent
operation. The module only remains imported for as long as PowerShell is
open. If you need to use the module again at a later time, you will have to
import it again.
Before you can import the module, you will have to configure your server’s
execution policy to allow PowerShell scripts to be run. The easiest way to do
this is to enter the following command:
Set-ExecutionPolicy Unrestricted
This command allows PowerShell to run any PowerShell script, regardless
of where it came from (Figure 4.20). Obviously, there are some security
implications associated with allowing unrestricted access to scripts, as
explained in the text shown below (Figure 4.20). If you are concerned about
security, you can set the execution policy back to Restricted when you finish
working with the AntiAffinityClassNames by using the Set-ExecutionPolicy
Restricted cmdlet.
Figure 4.20
You must configure the execution policy to allow PowerShell scripts to be run.
With that said, you can use the following command to import the module
(assuming that the module resides in C:\modules):
Import-Module C:\Modules\AntiAffinityClassNames
When you execute the command listed above, you will see several prompts
asking if you want to allow the script to run (Figure 4.21). You must run each of
these scripts in order to successfully import the module.
Figure 4.21
You must import the AntiAffinityClassNames module before you can use it.
As previously mentioned, a PowerShell module adds cmdlets to the built-in
cmdlet set. If you would like to see a list of the new cmdlets that were added,
enter the following command (Figure 4.22):
Get-Command –Module AntiAffinityClassNames
136
Understanding Hyper-V in Windows Server 2012
Figure 4.22
The AntiAffinityClassNames module adds three new cmdlets to PowerShell.
Now that all of the necessary components are in place, you can begin working
with anti-affinity rules. The basic idea behind these rules is that certain servers
should never reside on the same hosts. You can specify these servers by
adding a value to the AntiAffinityClassNames parameter. Servers with the same
AntiAffinityClassNames parameter will not normally fail over to a common host.
A more concrete example of how this works is a situation in which
an organization has multiple virtualized domain controllers. You would never
want to be in a situation in which all of your domain controllers failed over
to the same host. That being the case, you could add the phrase “Domain
Controller” to each domain controller’s AntiAffinityClassNames parameter
to indicate that each server that uses this tag is a domain controller and that
each domain controller should reside on a separate host. To be perfectly
clear, the “Domain Controllers” value is just an example—you can call your
anti‑affinity values anything that you want.
Setting up anti-affinity rules in this manner does not guarantee that the virtual
machines will never be hosted on the same server. If the cluster is ever put
into a situation where there aren’t enough remaining cluster nodes to facilitate
the requirements of the anti-affinity rules, Windows will place the virtual
machines wherever it can. The assumption is that it is more important to keep
the virtual machines running than it is to keep them separated.
Now you can configure anti-affinity rules by using the Set-AntiAffinityClassNames
cmdlet. This cmdlet requires you to specify the name of the cluster, the cluster
group to which the rule should apply (the cluster group name is the same as
the virtual machine name), and the value that you want to assign. Suppose, for
example, that your cluster is named HyperVCluster and that you want to assign
an AntiAffinityClassNames value of “Domain Controller” to a virtual machine
named VM3. To do so, use the following command:
Set-AntiAffinityClassNames –Cluster HyperVCluster –ClusterGroup VM3 –
Value “Domain Controller”
It is worth noting that the Set-AntiAffinityClassNames cmdlet sometimes
has trouble recognizing a cluster name. You may receive an error telling you
to check the spelling of the cluster name. If that happens, enter the GetAntiAffinityClassNames cmdlet (Figure 4.23). By doing so, you might find that
the cluster name is listed as localhost rather than by its designated name.
137
Understanding Hyper-V in Windows Server 2012
Figure 4.23
The cluster name is sometimes listed as localhost.
When you successfully assign a value to the AntiAffinityClassNames property,
PowerShell does not acknowledge the success of the operation. The easiest
way to confirm that the operation was successful is to enter the GetAntiAffinityClassNames cmdlet (Figure 4.24).
Figure 4.24
Use the Get-AntiAffinityClassNames cmdlet to verify the success of the operation.
Virtual machine prioritization
Failover clusters are great because if a cluster node fails, the virtual machines
can fail over to another node in the cluster where they continue to run.
Sometimes, however, the failover process fails because of insufficient
system resources.
Most Hyper-V failover clusters do not use empty cluster nodes that are sitting
idle, waiting for a failure to happen. More often, each cluster node hosts a
number of virtual machines. If a failure occurs, the Failover Cluster Service will
attempt to move the virtual machines from the failed node to another cluster
node where those virtual machines can continue to run. However, if the node
was already hosting some virtual machines prior to the failure, then that server
may not have enough memory or CPU resources to host its own workload plus
all of the virtual machines from the failed cluster node.
Unfortunately, there is no magic trick that you can use to make the cluster
node handle all of those virtual machines from the failed cluster node. Servers
only have so much memory and when all of that memory has been allocated,
the server will be unable to host any additional virtual machines.
Because Windows can’t expand a cluster node’s capacity so that it can handle
more virtual machines, Windows instead lets you prioritize virtual machines.
In any organization there are some virtual machines that are more important
than others. For example, your mail server is probably more important than
a redundant domain controller.
138
Understanding Hyper-V in Windows Server 2012
By prioritizing your virtual machines, you can make sure that the most
important virtual machines continue to function in a failover situation.
Windows will start the highest priority virtual machines first and lower priority
virtual machines in sequence until the server runs out of memory or other
resources.
Setting a virtual machine’s priority is easy. To do so, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager starts, select the Roles container.
4. Right-click on the virtual machine that you want to prioritize and choose
the Change Startup Priority command from the right-click menu
(Figure 4.25).
5. Specify the virtual machine’s priority.
Figure 4.25
Specify the virtual machine’s startup priority.
As you look at the figure above, you will notice that the Failover Cluster
Manager has a Priority column that displays each virtual machine’s priority.
Every virtual machine has a default priority of Medium, but you can raise
or lower that priority based on the virtual machine’s importance.
Setting the preferred owners
Some organizations might prefer to have virtual machines running on certain
hosts. For example, if you have a large database application, you would
probably want that application to run on the host that has the fastest CPU.
Hyper-V allows you to set priorities on which physical hosts your virtual
machines run. To specify a preferred host, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager opens, select the Roles container.
139
Understanding Hyper-V in Windows Server 2012
4. Right-click on a clustered virtual machine for which you want to specify
a preferred host server and select the Properties command from
the right‑click menu.
5. When the Core Properties dialog box appears, select the checkbox for
the virtual machine’s preferred host server (Figure 4.26).
Figure 4.26
Hyper-V allows you to specify a preferred host server for any clustered virtual machine.
Although Microsoft makes it easy to specify a preferred host, there are two
things that you should know about host server prioritization. First, you can
specify multiple preferred servers by selecting the checkboxes for each
preferred cluster node. Use the Up and Down buttons shown in the figure
above to arrange the list of cluster nodes based on your preferred priority.
Second, host prioritization is not guaranteed. If a virtual machine’s preferred
host is offline or lacks the capacity to host a virtual machine, the virtual
machine will be hosted on a cluster node other than the preferred node.
Failover rules
The Failover Cluster Service allows you to set some ground rules for the way
that virtual machines failover to other cluster nodes. These rules are all
controlled through a dialog box within the Failover Cluster Manager. To access
this dialog box, follow these steps:
1. Open the Server Manager.
2. Select the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, select the Roles container.
4. Right-click on a clustered virtual machine.
5. Select the Properties command from the right-click menu.
6. When the virtual machine’s properties sheet appears, select the Failover
tab (Figure 4.27).
140
Understanding Hyper-V in Windows Server 2012
Figure 4.27
Failover is controlled through the settings found on the Failover tab.
Note that the Failover tab is divided into two sections. The first section allows
you to define the maximum number of failovers that can occur within a given
period of time. The idea is that if a virtual machine fails over repeatedly, there
is probably a serious problem with that virtual machine or with the cluster
and it might be better to simply take the virtual machine offline and put it
into a failed state rather than allow it to keep failing over. By default, failures
are capped at two failures within a six-hour period, but you can adjust these
settings based on your needs.
The lower portion of the dialog box lets you control whether or not
the virtual machine will be allowed to fail back to the server on which it was
originally hosted. By default, automatic failback is disabled. However, you
can enable automatic failback and configure it to happen immediately or on
a scheduled basis.
In most cases it is best to leave automatic failback disabled. If a failover
occurred, a problem exists that caused the failover, and you don’t want
your virtual machines automatically failing back to a cluster node that has
an unresolved problem.
141
Understanding Hyper-V in Windows Server 2012
Chapter 5
PowerShell
Management
In Windows Server 2008 and 2008 R2, Microsoft allowed
many aspects of the Windows operating system to be
managed through PowerShell. Because PowerShell was
relatively new, however, there were certain operating
system components (including Hyper-V) that could not
be managed through PowerShell. Microsoft eventually
released a PowerShell module for Hyper-V, but this
module had to be downloaded separately. Thankfully,
the Windows Server 2012 version of Hyper-V includes
native PowerShell management capabilities. It is the goal
of this chapter to familiarize you with the various ways
in which Hyper-V can be managed through PowerShell.
142
Understanding Hyper-V in Windows Server 2012
Syntax simplification
Before discussing PowerShell management for Hyper-V, there is some
good news. While developing Windows Server 2012, Microsoft realized that
non‑developers often struggled with PowerShell. In spite of what the marketing
folks might say, the syntax for various PowerShell commands was often
complex and completely non-intuitive. Thankfully, Microsoft decided to simplify
the PowerShell syntax—especially as it relates to the Where-Object and
ForEach-Object cmdlets.
To show you an example of the way that the syntax has been simplified,
imagine that you want to see a list of all of the processes that are running on
the local Hyper-V host server. Prior to Windows Server 2012, you would have
had to use this command:
Get-Process | ForEach {$_.Name}
The Windows Server 2012 version of PowerShell is backward compatible
with the previous version, so you can still use this style of command (this is
important if you want to continue using older scripts). However, Windows
Server 2012 also allows you to enter commands in a simplified manner. For
example, the command shown above can be simplified as:
Get-Process | ForEach Name
This same simplification also applies to operations in which you use operators
to filter the result set. For example, prior to Windows Server 2012, to see a list
of all of the processes using more than 500 handles, you would have had to use
the following command:
Get-Process | where {$_.Handles –gt 500}
In Windows Server 2012, this command can be simplified as:
Get-Process | Where Handles –gt 500
143
Understanding Hyper-V in Windows Server 2012
Attaching to a Hyper-V server
The first skill you must master with regard to managing Hyper-V from
PowerShell is that of attaching to a remote server. If you plan to manage
Hyper-V through PowerShell by using the local server console, then you won’t
have to worry about establishing a remote PowerShell connection. You can
simply open a PowerShell window and enter the various cmdlets without
having to do anything special. However, if you need to manage a remote host,
you will first need to establish a session with that host.
There are a few different ways to use a PowerShell session to control a remote
Hyper-V host. One method involves using the Enter-PSSession cmdlet. To use
this method, enter the Enter-PSSession cmdlet and append the name of
the server that you want to attach to. Any commands that you run from this
point on will execute on the remote server, but the results will be displayed
in the local console. You can end the session by entering the Exit-PSSession
cmdlet. For example, to establish a session with a server named Lab2,
execute the Get-VM cmdlet, and then terminate the session, you would use
these commands:
Enter-PSSession Lab2
Get-VM
ExitPSSession
Notice in the screen capture (Figure 5.1) that the PowerShell prompt changes
to reflect the name of the server that you are attached to.
Figure 5.1
You can use the Enter-PSSession cmdlet to establish a remote PowerShell session.
Another method is to use the Invoke-Command cmdlet to execute a single
command on a remote host (Figure 5.2). The trick is to specify the computer
name. You can even specify multiple computer names if you separate them
by commas. The actual command that you send to the remote machines must
appear in braces. For example, to send the Get-VM command to computers
named Lab1, Lab2 and Lab3, you would enter the following command:
Invoke-command –ComputerName Lab1, Lab2, Lab3 {Get-VM}
144
Understanding Hyper-V in Windows Server 2012
Figure 5.2
You can use the Invoke-Command cmdlet to remotely execute a PowerShell command.
Keep in mind that these are the simplest methods of establishing a remote
PowerShell session. Things can become more complex if you need to enter
an alternative set of permissions or if you need to modify the execution
policy to allow scripts to be run. For example, the block of PowerShell listed
below is used to manage an Office 365 environment through PowerShell.
Although Office 365 is beyond the scope of this book, this example illustrates
the point that there are more complex methods of establishing remote
PowerShell connectivity.
Set-ExecutionPolicy RemoteSigned
Import-Module MSOnline
$Cred = Get-Credential
$MySession = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.outlook.com/powershell -Credential $Cred
-Authentication Basic -AllowRedirection
Import-PSSession $MySession
Querying virtual machines
One of the most basic (but useful) things that you can do with PowerShell
involves performing various queries against virtual machines. The simplest of
these queries involves using the Get-VM cmdlet. Entering this cmdlet returns
a list of all of the virtual machines that are present on the host (Figure 5.3).
Along with the name of each virtual machine, you can also see the virtual
machine’s state (whether or not it is running) along with its CPU usage,
memory assigned, up time and status.
145
Understanding Hyper-V in Windows Server 2012
Figure 5.3
The Get-VM cmdlet returns a list of the virtual machines that are present on the host.
Notice in Figure 5.3 that the Get-VM cmdlet returns virtual machine information
from the local server. Had we established a PowerShell session with a remote
server, virtual machine information from the remote server would have been
returned instead. If you need to perform a Get-VM query against a remote
server, however, it may not always be necessary to establish a session with the
server. Remote sessions are most useful when you need to redirect PowerShell
so that all operations are performed against the remote host instead of
the local host. If you simply need to retrieve a bit of information from the
remote host, you can often do so by using a standard PowerShell cmdlet and
appending the name of the remote server.
To see how this works, imagine that you want to see a list of the virtual
machines residing on a host named Prod1 (Figure 5.4). You can accomplish this
by entering the following command:
Get-VM –ComputerName Prod1
Figure 5.4
You can get a list of the virtual machines that reside on a specific host.
Of course, the list of virtual machines that are running on a specific host could
potentially be really long. Often you might be more interested in viewing
the state of a specific virtual machine rather than seeing a list of every virtual
machine that exists on a host server. In this case, you can append a virtual
machine name directly to the end of the Get-VM cmdlet (Figure 5.5). For
example, to view the current state of a VM named Lab-DC you can enter
this command:
Get-VM Lab-DC
Figure 5.5
You can retrieve information for a specific virtual machine.
146
Understanding Hyper-V in Windows Server 2012
Just as you can use the Get-VM cmdlet to retrieve basic information about
virtual machines, you can use the Get-VMHost cmdlet to access information
about host servers (Figure 5.6). Entering the Get-VMHost cmdlet by itself
returns the name of your host server along with its logical processor count,
memory capacity and whether or not the virtual machine is configured to allow
virtual machine migrations.
Figure 5.6
The Get-VMHost cmdlet retrieves information about a host server.
It is also possible to use the Get-VMHost cmdlet to retrieve information about
multiple host servers at the same time. Simply append the names of the host
servers that you want to query. Host server names should be separated
by commas (Figure 5.7). For example, the command might look something
like this:
Get-VMHost Lab1,Lab2,Lab3,Prod1,Prod2
Figure 5.7
You can query multiple host servers through a single command.
Filtering the output
In the previous section, you saw that it is possible to use the Get-VM
(Figure 5.8) and the Get-Host cmdlets to retrieve basic information about
virtual machines and host servers. Often, however, you might need to access
more detailed information than what these cmdlets provide by default.
Fortunately, there are a number of ways to accomplish this.
Figure 5.8
You can use the Get-VM cmdlet to retrieve virtual machine information.
147
Understanding Hyper-V in Windows Server 2012
One of the nice things about PowerShell is that it allows you to use attributes
and operators to filter a cmdlet’s output. Some of the commonly used
operators include:
Equal To
-EQ
Or
-OR
And
-AND
Like
-Like
Greater Than -GT
Less Than
-LT
You can combine these operators with object attributes to retrieve very
granular information about your host servers and virtual machines.
One of the most basic examples of output filtering involves filtering virtual
machines by name. For example, entering the Get-VM cmdlet on the host Lab1
returns listings for a number of virtual machines. On this server the name of
each virtual machine reflects the virtual machine’s purpose. For example, virtual
machines starting with LAB15 are lab machines related to Microsoft’s wave 15
product release (Office 15, SharePoint 15, Exchange 15, etc.).
With this in mind, it might occasionally be necessary to get a list of the virtual
machines that are related to wave 15 testing. In this situation, the Like operator
could prove to be very handy. You can use the Like operator to list values that
are similar to a target value. For instance, you can list all of the virtual machines
that have names starting with Lab15 (Figure 5.9) by using the following cmdlet:
Get-VM | Where Name –Like ‘Lab15*’
Figure 5.9
You can use filtering to narrow down the list of virtual machines.
Being able to filter virtual machines by name is nice, but this is not the only
type of filtering you can do. It is also possible to filter on things like a virtual
machine’s state. For instance, if you want to see which virtual machines are
currently powered off (Figure 5.10), you can use the following command:
Get-VM | Where State –EQ ‘Off’
Figure 5.10
You can filter based on a virtual machine’s state.
148
Understanding Hyper-V in Windows Server 2012
Obviously it’s handy to be able to see a list of the virtual machines that are
powered off, but remember that the command shown above only looks
at the current host server. What if you wanted to see a list of the running virtual
machines across multiple hosts? To accomplish this, you would simply add
the –ComputerName switch and the names of the hosts that should be
included in the query (Figure 5.11). The command might look something
like this:
Get-VM –ComputerName Lab1,Lab2,Lab3,Prod1,Prod2 | Where State –EQ
‘Running’
Figure 5.11
A filtered output can contain data from multiple Hyper-V host servers.
What about clusters?
So far the topic of filtering has assumed that the virtual machines are running
on standalone hosts. However, virtual machine queries can also be very useful
in clustered environments. Suppose, for example, that you want to see a list of
all of your clustered virtual machines (Figure 5.12). You can do so by entering
the following command:
Get-ClusterGroup | Where GroupType –EQ ‘VirtualMachine’ | Get-VM
Figure 5.12
You can use PowerShell for cluster management.
This technique becomes most useful when you apply multiple filters together.
If you look at the previous screen capture you will notice that one clustered
virtual machine is running and another is not. If this were a production
environment with lots of virtual machines, it might be useful to compile a list of
the clustered virtual machines that were not running (Figure 5.13). You could do
this by entering the following command:
Get-ClusterGroup | Where GroupType –EQ ‘VirtualMachine’ | Get-VM | Where
State –EQ ‘Off’
Figure 5.13
You can create a list of clustered virtual machines that are not currently running.
149
Understanding Hyper-V in Windows Server 2012
In a clustered environment it isn’t just important to keep virtual machines
running, it is also important to keep track of resource utilization. You can use
a similar technique to the one that was just demonstrated to keep track of
virtual machine memory usage within the cluster. For example, to create a list
of all of the clustered virtual machines that are using more than a gigabyte of
memory (Figure 5.14), you can use this command:
Get-ClusterGroup | Where GroupType –EQ ‘VirtualMachine’ | Get-VM | Where
MemoryAssigned –GT ‘1073741825’
Figure 5.14
You can use PowerShell to determine which VMs are consuming excessive system resources.
It is worth noting that even though PowerShell displays the memory in
megabytes in this case, you must enter the MemoryAssigned value in bytes.
Getting more information
So far, this chapter has discussed various filtering techniques, but often you
may need more detailed information than what the various commands provide
by default. The good news is that the Get-VM and the Get-VMHost cmdlets
only display a small subset of the information that is actually available and it
is easy to customize the commands so that just the information you need
is displayed.
In PowerShell, VM and VMHost both represent objects. Objects contain
a collection of attributes. Therefore, the key to customizing the command
output is controlling which attributes are displayed. To see the attributes
that are available for the Get-VM cmdlet (Figure 5.15), enter the following
command:
Get-VM Lab-DC | FL *
150
Understanding Hyper-V in Windows Server 2012
Figure 5.15
A wealth of information is available for each virtual machine.
This command displays all of the available attributes in list format. Pay
attention to the attribute names because you can use these names to
customize the output or to apply filters. Similarly you can view all of the
attributes that are available within the Get-VMHost cmdlet (Figure 5.16) by
entering this command:
Get-VMHost | FL *
151
Understanding Hyper-V in Windows Server 2012
Figure 5.16
You can use the Get-VMHost cmdlet to retrieve host server information.
As you can see, there is a lot of information available both for virtual machines
and for host servers. But what can you do with all of this information?
For starters, you can control the output of the Get-VM or the Get-VMHost
cmdlets (Figure 5.17). For example, suppose that you want to see each virtual
machine’s name, the name of the host on which the virtual machine currently
resides and whether or not the virtual machine is clustered. You can accomplish
this by entering the following command:
Get-VM | FT VMName, ComputerName, IsClustered
Figure 5.17
You can control the output of the Get-VM or the Get-VMHost cmdlets.
Of course, you output the values of any of the available attributes and you can
also use the various attributes with operators such as –Like, -And, -GT, etc.
to achieve a filtered output.
It is worth noting that Microsoft provides a number of cmdlets that you can
use as shortcuts to retrieve very specific information about virtual machines.
For example, you can use the Get-VMMemory cmdlet to retrieve a virtual
machine’s memory configuration. Likewise, you can use the Get-VMProcessor
cmdlet to view a virtual machine’s virtual CPU configuration.
152
Understanding Hyper-V in Windows Server 2012
Reporting
In the previous section you learned how to modify the Get-VM
and the Get‑VMHost cmdlets to achieve the desired output, but you can
actually take things a step further and use PowerShell as a reporting engine.
You can use PowerShell to create CSV, Text and even HTML files.
Lists and tables
Before moving on to the creation of these file types, there is one more aspect
of the output formatting to discuss. In the previous sections, the codes FL 9
(Format-List) and FT (Format-Table) were used. Formatting a command’s
output as a list (Figure 5.18) displays the information vertically. This is the most
appropriate format for viewing large amounts of information on screen. Tables
(Figure 5.19) display information horizontally. This table format is best for
looking at multiple results, such as a listing of virtual machines.
Figure 5.18
Lists display information vertically.
153
Understanding Hyper-V in Windows Server 2012
Figure 5.19
Tables display data horizontally.
It is fine to use FT and FL to view a command’s output on screen, but if you
plan to write the output to a CSV or HTML file, this will not work. Instead,
you will have to replace FT or FL with the Select-Object cmdlet (Figure 5.20),
followed by the attributes that you want to display. For example, you might use
a command like this one:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status
Figure 5.20
Often, it is necessary to use the Select-Object cmdlet to specify what data to include
in a report.
154
Understanding Hyper-V in Windows Server 2012
CSV files
CSV files are almost always created in table format. CSV files are useful
for outputting large amounts of information in a format that can be read
by Microsoft Excel or imported into a database. You can create a CSV file by
appending the Export-CSV cmdlet to whatever command you are using. It
is worth noting, however, that you must manually specify the attributes to
include in the output. For example, to create a CSV file containing a listing of
your virtual machines, their state, the host, whether or not the virtual machine
is clustered, and the virtual machine’s uptime and status (Figure 5.21), you can
enter this command:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | Export-CSV C:\Data\VMs.csv
Figure 5.21
You can choose which fields to export to a CSV file.
Once created, you can open the CSV in Microsoft Excel (Figure 5.22).
Figure 5.22
You can open CSV files in Microsoft Excel.
Text files
The process of creating a text file is similar to that of creating a CSV file,
but PowerShell is a bit more forgiving when it comes to creating text files.
You don’t have to use the Select-Object cmdlet and can instead use FT or FL.
Rather than using the Export-CSV cmdlet, you will use the Out-File cmdlet.
Other than that, the commands are identical. For example, to write a list of
virtual machines to a text file (Figure 5.23), you can use this command:
Get-VM | FT VMName, State, ComputerName, IsClustered, UpTime, Status |
Out-File C:\Data\VMs.txt
155
Understanding Hyper-V in Windows Server 2012
Figure 5.23
You can write PowerShell data to a text file.
Notice in Figure 5.23 that you can view the contents of the newly created
text file by entering the Type command, followed by the path and filename
of the text file. Of course, you can also open the file in Notepad or any other
text editor.
HTML reports
The process of creating an HTML report is similar to that of creating a text
file—both use the Out-File cmdlet. However, to create an HTML report,
you need to add the ConvertTo-HTML cmdlet. For example, to write a list of
your virtual machines to an HTML file, use this command:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | ConvertTo-HTML | Out-File C:\Data\VMs.htm
Just for fun, you can modify this command so that it creates the report
and automatically opens it in Internet Explorer (Figure 5.24). To do this,
append the Invoke-Expression cmdlet to the end of the command as shown
in the following example:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | ConvertTo-HTML | Out-File CL\Data\VMs.htm | InvokeExpression C:\Data\VMs.htm
Figure 5.24
You can write PowerShell data to an HTML report.
As you can see, the process of writing data to an HTML report works pretty
well, but the report is very plain (Figure 5.25) and not very visually appealing.
To make your reports more visually interesting, you can create a style section
and incorporate it into the report.
156
Understanding Hyper-V in Windows Server 2012
Figure 5.25
By default, HTML reports are very bland.
The block of code below (Figure 5.26) creates a PowerShell variable named
$a and then adds an HTML style section to that variable. The actual report is
created as discussed earlier, but with a couple of differences. When it comes
time to issue the ConvertTo-HTML command, you insert the –Head switch
and the $a variable. You also insert the Body tag and a header. The end result
is a much more attractive HTML report (Figure 5.27). This is how the code
is written:
$a = "<style>"
$a = $a + "BODY{background-color:peachpuff;}"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color:
black;border-collapse: collapse;}"
$a = $a + "TH{border-width: 1px;padding: 0px;border-style: solid;bordercolor: black;background-color:thistle}"
$a = $a + "TD{border-width: 1px;padding: 0px;border-style: solid;bordercolor: black;background-color:PaleGoldenrod}"
$a = $a + "</style>"
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | ConvertTo-HTML -head $a -body "<H2>Virtual Machines</
H2>" | Out-File C:\Data\VMs.htm
Figure 5.26
You can add HTML style elements to an HTML report.
157
Understanding Hyper-V in Windows Server 2012
Figure 5.27
HTML reports can be displayed in color.
With a little bit of imagination you can create scripts that produce color-coded
reports. For example, you can list virtual machines that are offline in red and list
online virtual machines in green.
Changing a virtual machine’s state
So far we have discussed PowerShell solely with regard to retrieving
information about a virtual machine or a host server. Although PowerShell
can be a powerful reporting tool, it can also be used to interact with
virtual machines. For example, you can use PowerShell to start or stop
a virtual machine.
There are two cmdlets you can use to change a virtual machine’s state.
These include:
Stop-VM
Start-VM
When you enter the Stop-VM cmdlet, PowerShell will attempt to gracefully shut
down the specified virtual machine. If the virtual machine cannot be brought
down gracefully, you will see a warning message (Figure 5.28) telling you that
the virtual machine cannot be shut down. The message gives you the option
of turning off the virtual machine (without a graceful shutdown) or suspending
the virtual machine.
Figure 5.28
You will see a warning message if a virtual machine cannot be shut down gracefully.
The Start-VM cmdlet starts the virtual machine. The only required parameter is
the name of the virtual machine that you want to start (Figure 5.29).
158
Understanding Hyper-V in Windows Server 2012
Figure 5.29
You can use the Start-VM cmdlet to start a virtual machine.
Creating a virtual machine
You can also use PowerShell to create virtual machines. This involves using
the New-VM cmdlet. At a minimum, you need to specify the name for the new
virtual machine, the virtual machine path and the name of the host on which
the virtual machine will reside. For example, to create a virtual machine named
PowerShellVM in the C:\VMs folder on a host named Lab1 (Figure 5.30), you
would enter the following command:
New-VM –Name “PowerShellVM” –Path “C:\VMs” –ComputerName Lab1
Figure 5.30
You can create virtual machines through PowerShell.
When you enter this command, you will see confirmation that the new virtual
machine was created. The new virtual machine should also be displayed in
the Hyper-V Manager (Figure 5.31).
Figure 5.31
The new virtual machine should appear in the Hyper-V Manager.
159
Understanding Hyper-V in Windows Server 2012
Keep in mind that you will almost always have to make modifications to a newly
created virtual machine before using it. When you create a virtual machine
using the method discussed above, it is allocated minimal hardware that is
almost never suitable for real world use. The hardware allocation includes:
• 512 MB of memory
• DVD drive
• No virtual hard disk
• No network connection
• One virtual processor
Fortunately, you can use PowerShell cmdlets to modify a new or an existing
virtual machine.
Modifying a virtual machine
As you saw in the previous section, you may need to modify a virtual machine
after creating it through PowerShell. Likewise, you may occasionally need
to modify an existing virtual machine’s configuration. For instance, you might
need to add more memory or additional CPU cores to a virtual machine.
This section discusses some techniques for modifying virtual machine
hardware allocation.
Memory
The resource that you will likely have to adjust more often than any other is
memory. You can adjust memory by using the Set-VMMemory cmdlet.
Start the process by entering the Get-VMMemory cmdlet, followed by
the name of the virtual machine (Figure 5.32). This causes PowerShell to display
the virtual machine’s current memory configuration.
Figure 5.32
You can use the Get-VMMemory cmdlet to see a virtual machine’s memory assignment.
The easiest way to reallocate a virtual machine’s memory is to assign a static
amount of memory to the virtual machine by entering the following command:
Set-VMMemory <virtual machine name> –Startup <memory amount>
For example, to add 2 GB of memory to the virtual machine named
PowerShellVM (Figure 5.33), use the following command:
Set-VMMemory PowerShellVM –Startup 2.0GB
160
Understanding Hyper-V in Windows Server 2012
Figure 5.33
You can use the Set-VMMemory cmdlet to allocate memory to a virtual machine.
This command sets the startup memory to 2 GB. You can verify the operation’s
success by using the Get-VMMemory cmdlet.
If you want to configure a virtual machine to use dynamic memory, things
become a bit more complicated. You still use the Set-VMMemory cmdlet,
but you have to include a specification to enable dynamic memory. You will
also have to provide values for the minimum, startup and maximum memory.
You can optionally set a priority and a buffer value for the virtual machine as
well by using the following command:
Set-VMMemory <virtual machine name> -DynamicMemoryEnabled $True
–MinimumBytes <minimum memory> -StartupBytes <startup memory>
-MaximumBytes <maximum memory> -Priority <priority> -Buffer
<buffer value>
For example, suppose you want to configure the virtual machine PowerShellVM
to use a 1 GB of startup memory and you want to set the minimum memory
to 512 MB and the maximum memory to 2 GB. Let’s also assume that you want
to set the priority to 80 and the buffer to 25 (Figure 5.34). You can do this with
the following command:
Set-VMMemory PowerShellVM –DynamicMemoryEnabled $True –
MinimumBytes 512MB -StartupBytes 1GB –MaximumBytes 2GB –Priority 80
–Buffer 25
Figure 5.34
You can also use the Set-VMMemory for configuring dynamic memory.
Now that you know how to allocate memory to a virtual machine, here are
a couple of shortcuts that you can use. Keep in mind that you can use these
shortcuts with any type of hardware allocation. The following example uses
only memory allocation.
161
Understanding Hyper-V in Windows Server 2012
Allocating memory to multiple virtual machines
The first shortcut allows you to allocate memory to multiple virtual machines
simultaneously. The easiest way to accomplish this is to specify multiple virtual
machine names within the Set-VMMemory cmdlet. For example, to allocate
2 GB of memory to virtual machines named NewVM1, NewVM2 and NewVM3
on a server named Lab1 (Figure 5.35), you can use the following command:
Set-VMMemory NewVM1,NewVM2,NewVM3 –Startup 2.0GB
Figure 5.35
You can assign memory to multiple virtual machines.
When the operation has completed, you can verify its success by specifying all
three virtual machine names within the Get-VMMemory cmdlet. For example,
in this situation you would enter:
Get-VMMemory NewVM1,NewVM2,NewVM3
Keep in mind that this is not the only way to allocate memory to multiple
virtual machines. You can also specify the virtual machines to which you want
to allocate memory using filtering. For example, you can create a filter based
on the virtual machine’s name or on the amount of memory that is currently
allocated to the virtual machine.
Pipelining hardware allocations
The other shortcut that is worth knowing is that you can actually allocate
memory to a virtual machine while the virtual machine is being created. This is
done by pipelining the New-VM and the Set-VMMemory cmdlets together.
Suppose, for example, that you want to create a virtual machine named
NewVM4 and allocate 4 GB of RAM to it (Figure 5.36). You can accomplish this
by using the following command:
New-VM –Name “NewVM4” –Path “C:\VMs” –ComputerName Lab1 | SetVMMemory –Startup 4GB
Figure 5.36
You can assign startup memory as a virtual machine is being created.
162
Understanding Hyper-V in Windows Server 2012
Virtual network adapters
Just as you may need to modify a virtual machine’s memory allocation,
you may also need to provision a virtual machine with a virtual NIC. It’s best
to start by viewing a virtual machine’s current virtual network adapter usage.
To do this, enter the Get-VMNetworkAdapter cmdlet, followed by the virtual
machine name (Figure 5.37).
Figure 5.37
You can use the Get-VMNetworkAdapter cmdlet to access virtual network adapter
information for a virtual machine.
In many cases, you may find that although a network adapter has been
assigned to a virtual machine, you must connect that network adapter
to a virtual switch. Fortunately, this is relatively easy to do. While it is possible
to use a single command to attach a virtual network adapter to a virtual
switch, it’s better to use variables because the virtual network adapter name
and the virtual switch name may be long. Using variables reduces the chances
of making a mistake by mistyping one of the names.
Therefore, the first step in the process is to retrieve the name of the virtual
machine’s virtual network adapter and assign this name to a variable named
$VMNic using the following command:
$VMNic = Get-VMNetworkAdapter –VMName <virtual machine name>
The next step is to retrieve the name of the virtual switch by using
the following command:
Get-VMSwitch | Select-Object Name
If you have multiple virtual switches, you can narrow down the results by
specifying the virtual switch’s connectivity. For example, if you only want to use
an external virtual switch, you can use the following cmdlet:
Get-VMSwitch –SwitchType External | Select-Object Name
Now you just need to connect the virtual network adapter to the virtual switch.
You should be able to do this by using the Connect-VMNetworkAdapter
cmdlet; however, PowerShell apparently doesn’t allow you to add the virtual
switch name to a variable and use the variable to connect the virtual switch
to a virtual network adapter. Instead, you have to enter the virtual switch name
in long form. The command looks something like this:
Connect-VMNetworkAdapter –VMNetworkAdapter $VMNic –SwitchName
“<virtual switch name>”
163
Understanding Hyper-V in Windows Server 2012
As a more concrete example, for the virtual switch on a test server named
Intel(R) Gigabit CT Desktop Adapter #2 – Virtual Switch (Figure 5.38), you would
use the following command:
Connect-VMNetworkAdapter –VMNetworkAdapter $VMNic –SwitchName
“Intel(R) Gigabit CT Desktop Adapter #2 – Virtual Switch”
Figure 5.38
You must connect a virtual network adapter to a virtual switch.
Once you have connected the virtual network adapter to the virtual switch,
it is a good idea to verify the connection (Figure 5.39). You can do by entering
the following command:
Get-VMNetworkAdapter –VMName <your virtual machine name> | SelectObject VMName, Name, SwitchName
Figure 5.39
You can use the Get-VMNetworkAdapter cmdlet to verify the connection.
CPU cores
When you create a new virtual machine through PowerShell, Windows
automatically assigns a single virtual processor to the virtual machine. In some
cases, however, a single virtual processor might not be sufficient. Fortunately,
PowerShell makes it possible to add virtual processors to a virtual machine.
Before you attempt to modify a virtual machine’s virtual processor allocation,
it is a good idea to verify the number of virtual processors currently
assigned to the virtual machine (Figure 5.40). You can do this by using
the following command:
Get-VM <virtual machine name>| Select-Object VMName, ProcessorCount
Figure 5.40
It’s a good idea to verify a virtual machine’s current virtual CPU count.
Once you have verified the virtual machine’s current virtual processor
count, you can modify the number of virtual processors that are assigned
to the virtual machine by using the following command:
Set-VMProcessor <virtual machine name> -Count <number of virtual CPUs>
164
Understanding Hyper-V in Windows Server 2012
For example, to assign two virtual processors to a virtual machine named
NewVM1 (Figure 5.41), you can use this command:
Set-VMProcessor NewVM1 –Count 2
Figure 5.41
You can use the Set-VMProcessor cmdlet to configure a virtual machine’s virtual CPU usage.
Of course there are also some other switches that you can use with
the Set‑VMProcessor cmdlet. For instance, if you want to set a reserve,
maximum and relative weight value, you can use a command like this:
Set-VMProcessor <virtual machine name> -Count 2 –Reserve 10 – Maximum
75 – RelativeWeight 200
In case you are not familiar with these particular values, here are their
meanings:
• Limit –The maximum amount of time that a virtual machine is allowed
to use a physical CPU. The default limit is 100% usage.
• Reservation – A percentage of CPU time solely for a specific virtual
machine. By default the reservation is set at 0%.
• Weight – A relative weight that affects how much CPU time a virtual
machine will receive. The default weight is 100.
You can also use the Set-VMProcessor cmdlet to enable compatibility for
older operating systems by including the –Compatibility For Older Operating
Systems Enabled switch in the command, as in the following example:
Set-VMProcessor <virtual machine name>
-CompatibilityForOlderOperatingSystemsEnabled $true
Building a virtual machine from scratch
Earlier in this chapter you saw that it is possible to build a virtual machine
by using the New-VM cmdlet. However, when you use a minimum set of
switches with this cmdlet, the virtual machine is lacking, to say the least.
In fact, the newly created virtual machine doesn’t even have a virtual hard
disk. There are a couple of ways to overcome this problem—the easiest way
being to provision the virtual machine while it is being created. Although this
approach can complicate the New-VM command, it does allow you to create
a fully provisioned virtual machine using a single command.
For example, to create a new virtual machine named NewVM4 that has
a 50-GB virtual hard drive and is located at F:\NewVM4, you could enter
the following command:
New-VM –Name NewVM4 –NewVHDPath F:\NewVM4\disk1.VHDX –
NewVHDSize 50GB –Path F:\NewVM4
165
Understanding Hyper-V in Windows Server 2012
This command (Figure 5.42) works really well for creating a virtual machine
and its virtual hard disk. The problem is that the virtual machine is still a bit
lacking. By default, this virtual machine is only equipped with 512 MB of
memory, a single virtual processor, and the virtual network adapter is not
connected to a virtual switch (Figure 5.43). Never mind the fact that you might
need to create some additional virtual hard disks for the virtual machine.
Figure 5.42
You can create a virtual hard disk and a virtual machine at the same time.
Figure 5.43
By default, a new virtual machine is provisioned with a very modest amount
of hardware resources.
Unfortunately, you can’t do much more with the New-VM cmdlet. You can
specify startup memory, but that’s about it. That being the case, what follows
is a set of line-by-line instructions for creating and provisioning a new
virtual machine.
166
Understanding Hyper-V in Windows Server 2012
This example illustrates how to create a new virtual machine named NewVM5.
The virtual machine will be equipped with two 50-GB virtual hard disks, two
gigabytes of virtual memory, four virtual processors, and it will be connected
to a virtual switch.
Start by creating the virtual machine and its 50-GB boot drive (Figure 5.44),
using the following command:
New-VM –Name NewVM5 –NewVHDPath F:\NewVM5\disk1.VHDX –
NewVHDSize 50GB –Path F:\NewVM5
Figure 5.44
You can create a new virtual machine from the command line.
Now that you have created the virtual machine, you need to provision it. Start
by adding the second 50-GB virtual hard disk (Figure 5.45). You can create
a new hard disk using this command:
New-VHD F:\NewVM5\Disk2.VHDX –Size 50GB
Figure 5.45
You have created a dynamically expanding virtual hard disk.
This command created a 50-GB dynamically expanding virtual hard disk.
The problem is that the virtual hard disk is still not attached to the virtual
machine. You can verify this by entering the Get-VMHardDiskDrive command,
followed by the name of the virtual machine (Figure 5.46).
Figure 5.46
The new virtual hard disk is not attached to the virtual machine.
167
Understanding Hyper-V in Windows Server 2012
This command not only displays the virtual hard disks that are in use, it also
shows which IDE ports are currently in use. When you join the newly created
virtual hard disk to the virtual machine, you will have to choose a set of
ports that are not in use. For example, to use IDE port 0.1 you would use
this command:
Add-VMHardDiskDrive NewVM5 IDE 0 1 –Path F:\NewVM5\Disk2.vhdx
The command does not generate any output, so to verify its success you need
to reissue the Get-VMHardDiskDrive cmdlet (Figure 5.47) as shown below:
Get-VMHardDiskDrive NewVM5
Figure 5.47
You must add the virtual hard disk to the virtual machine.
Now that the virtual hard disks are in place, you simply need to provision
memory, CPU and network connectivity. The task of provisioning memory
and CPU resources to the new virtual machine is easy (Figure 5.48) and can be
accomplished using these commands:
Set-VMMemory NewVM5 –Startup 4GB
Set-VMProcessor NewVM5 –Count 4
Figure 5.48
Adding CPU and memory resources to the virtual machine is easy.
The last step in the process is to connect the virtual network adapter
to the virtual switch. As you may recall, this isn’t a single-step process. You
have to retrieve both the name of the virtual network adapter and the name
of the virtual switch (Figure 5.49). To retrieve the name of the virtual adapter,
use the following command:
$VMNic = Get-VMNetworkAdapter –VMName <virtual machine name>
Next, you need to retrieve the name of the virtual switch. You can do this by
using the following command:
Get-VMSwitch | Select-Object Name
Now you need to connect the virtual network adapter to the virtual switch by
using this command:
Connect-VMNetworkAdapter –VMNetworkAdapter $VMNic –SwitchName
“<virtual switch name>”
You can use the following command to verify connectivity:
Get-VMNetworkAdapter –VMName <your virtual machine name> | SelectObject VMName, Name, SwitchName
168
Understanding Hyper-V in Windows Server 2012
Figure 5.49
Connecting the virtual machine to the network requires a few steps.
The new virtual machine is now fully provisioned. You can verify all of
the virtual machine settings through the Hyper-V Manager (Figure 5.50).
Figure 5.50
You can use the Hyper-V Manager to verify the virtual machine settings.
169
Understanding Hyper-V in Windows Server 2012
Deleting a virtual machine
To delete a virtual machine, use the Remove-VM cmdlet. The only required
parameter is the name of the virtual machine that you want to delete.
Forexample, if you want to delete a virtual machine named NewVM4,
use this command:
Remove-VM NewVM4
When you enter this command, Hyper-V will prompt you for confirmation
(Figure 5.51) before deleting the virtual machine.
Figure 5.51
You can use the Remove-VM cmdlet to delete a virtual machine.
Working with virtual machine snapshots
One of the most frequently used features in Hyper-V is snapshots. Snapshots
allow an administrator to protect a virtual machine prior to performing
a potentially dangerous operation. For example, many administrators are in
the habit of creating a snapshot prior to applying a service pack to a virtual
machine. That way, if the service pack happens to cause problems, the virtual
machine can be easily reverted to a previous state.
Snapshotting through PowerShell can be a bit complex, but the following
examples will give you the basics of how it works. To take a snapshot of
a virtual machine, you can use this command:
Get-VM <virtual machine name> | Checkpoint-VM
For example, to create a snapshot of a virtual machine named NewVM1
(Figure 5.52), you can enter the following command:
Get-VM NewVM1 | Checkpoint-VM
Figure 5.52
The Checkpoint-VM cmdlet is used to create snapshots.
After you have created a snapshot, you probably want to verify that
the snapshot exists. One way of doing this is to select the virtual machine
within the Hyper-V Manager and look at the Snapshots pane (Figure 5.53).
Of course, this chapter is all about PowerShell, so if you want to verify
the snapshot through PowerShell, you can use the Get-VMSnapshot cmdlet
(Figure 5.54) shown below:
Get-VMSnapshot –VMName <Virtual machine name>
170
Understanding Hyper-V in Windows Server 2012
Figure 5.53
The new snapshot is visible through the Hyper-V Manager.
Figure 5.54
You can view snapshots through PowerShell.
Things get a bit trickier if you want to restore a snapshot in order to revert
a virtual machine to a prior state. You can roll back a virtual machine by using
the Restore-VMSnapshot command (Figure 5.55). This command requires you
to provide the name of the virtual machine and the name of the snapshot. You
can enter this information manually, but it is a lot easier to use a command like
this one:
Restore-VMSnapshot –Name (Get-VMSnapshot –VMName “<virtual machine
name>”).Name –VMName “<virtual machine name>”
Figure 5.55
You can use the Restore-VMSnapshot cmdlet to revert a VM to a previous state.
For example, if you want to roll back a virtual machine named NewVM1
to the state in which it existed when the most recent snapshot was created,
you can use this command:
Restore-VMSnapshot –Name (Get-VMSnapshot –VMName “NewVM1”).Name
–VMName “NewVM1”
When you enter this command, PowerShell will prompt you to confirm that you
want to perform the rollback.
171
Understanding Hyper-V in Windows Server 2012
If you decide instead to remove the most recently created virtual machine
snapshot, the command syntax is exactly the same, except that you
would use the Remove-VMSnapshot cmdlet (Figure 5.56) instead of
the Restore‑VMSnapshot cmdlet. The syntax is as follows:
Remove-VMSnapshot –Name (Get-VMSnapshot –VMName “<virtual machine
name>”).Name –VMName “<virtual machine name>”
Figure 5.56
The Remove-VMSnapshot cmdlet is used to delete unwanted snapshots.
It is worth noting that this command does not prompt you for confirmation
before deleting the snapshot. Therefore, you should exercise extreme caution
when using the Remove-VMSnapshot cmdlet.
Live migration of a virtual machine
Live migrations are one of the easier functions to perform through PowerShell.
The PowerShell cmdlet for live migrations is Move-VM. At a minimum
this cmdlet requires you to specify the virtual machine name and the name
of the host server to which the virtual machine will be moved. For example,
to move the virtual machine named NewVM3 to the server Lab2, you use
this command:
Move-VM “NewVM3” Lab2
The problem is that the above command moves the virtual machine itself,
but not the virtual machine’s storage. Therefore, the command is only
appropriate if the virtual machine’s files reside on SMB storage.
In most cases, you need to specify the destination storage path as
an additional switch. To see how this works, imagine that you want to move
the virtual machine NewVM3 to server Lab2 and you want to store the virtual
machine files in F:\VMs (Figure 5.57). You can perform the migration using
this command:
Move-VM “NewVM3” Lab2 –DestinationStoragePath F:\VMs
Figure 5.57
Use the Move-VM cmdlet for live migrations.
172
Understanding Hyper-V in Windows Server 2012
Getting help
Although you can do a lot with regard to managing Hyper-V through
PowerShell, the PowerShell cmdlets and their syntaxes are sometimes
difficult to remember. Fortunately, Microsoft provides a number of different
mechanisms to help you use PowerShell.
The question mark switch
Throughout this chapter you have probably noticed that PowerShell cmdlets
can sometimes use a number of optional switches. Therefore, one of the keys
to using PowerShell effectively is to determine all the options for a particular
cmdlet. This is easier to accomplish than it might seem. To see a list of
the options that can be used with a cmdlet, simply enter the cmdlet followed
by the -? switch (Figure 5.58). For example, to see all of the options for using
the Get-VM cmdlet, enter the following command:
Get-VM -?
Figure 5.58
The question mark switch is used to retrieve the full syntax for any PowerShell cmdlet.
Any time you use the question mark switch, PowerShell asks you if you want
to run the Update-Help cmdlet. The Update-Help cmdlet causes PowerShell
to download the latest help files from the Internet. When the help file update
completes, the full command syntax will be displayed.
Get-Help
PowerShell cmdlets are a combination of nouns and verbs. Sometimes,
however, it can be difficult to remember what noun-verb combinations can be
used together, and this is where the Get-Help cmdlet comes into play. Get-Help
can show you all of the nouns that can be used with a particular verb or all of
the verbs that can be used with a specific noun. For example, in Hyper-V many
of the cmdlets are designed to be used on virtual machines and therefore use
VM as a noun (Get-VM, Set-VM, etc.). If you want to see all of the actions that
can be performed on a VM (Figure 5.59), you can use the following command:
Get-Help *-VM
173
Understanding Hyper-V in Windows Server 2012
Figure 5.59
These are all of the verbs that can be used with the VM noun.
As previously mentioned, Get-Help can be used with both nouns and verbs.
Notice in Figure 5.59 that the last cmdlet on the list is Suspend-VM. If you are
curious as to whether the Suspend verb can be used with nouns other than VM,
you can enter this command:
Get-Help Suspend-*
When you enter this command (Figure 5.60), you will see that PowerShell
uses the Suspend verb for a number of different purposes, some of which are
not even related to Hyper-V. For example, you can use the Suspend verb to
suspend a service or a print job.
Figure 8.60
The Get-Help cmdlet can help you to figure out what noun and verb combinations will
work together.
What-If
As you have no doubt noticed throughout this chapter, some PowerShell
commands are complicated. That being the case, it would be nice to have
a way to make sure that you are entering the correct command before you
actually press Enter. The good news is that Windows gives you a way to
find out what a specific PowerShell command would do before you actually
execute the command. The trick is to append the –WhatIf switch to the end of
the command.
For example, suppose that you weren’t quite sure what would happen if you
executed the New-VM command. You could append the –WhatIf switch to
the command (Figure 5.61) and PowerShell would tell you that the command
would create a new virtual machine named New Virtual Machine.
Figure 5.61
The WhatIf switch is used to find out what will happen if you perform a certain command.
174
Understanding Hyper-V in Windows Server 2012
It is worth noting that not every PowerShell cmdlet can be used with
WhatIf. To see which cmdlets support the use of WhatIf (Figure 5.62), enter
the following command:
Get-Command | Where Definition –Like *whatif*
Figure 5.62
Not every cmdlet works with the WhatIf switch.
IntelliSense
In addition to the PowerShell interface that is shown throughout this chapter,
Microsoft also provides a feature called the PowerShell Integrated Scripting
Environment (ISE). In the Windows Server 2012 version of PowerShell,
the Integrated Scripting Environment contains a feature called IntelliSense,
which anticipates the command that you are about to type and offers help as
you enter the command.
To see how this feature works, go to your Hyper-V server’s Metro interface,
click the Administrative Tools tile and double-click on the Windows PowerShell
ISE command (Figure 5.63), which is found on the Administrative Tools list.
175
Understanding Hyper-V in Windows Server 2012
Figure 5.63
The Windows PowerShell ISE icon is found on the Administrative Tools menu.
When the Windows PowerShell ISE window opens, start typing a PowerShell
command. As you type, the IntelliSense feature will engage and help you with
the command’s syntax (Figure 5.64). For instance, if you type New-V, then
IntelliSense will show you all of the cmdlets that start with New-V. As you
progress through the list of commands, IntelliSense even offers syntax help.
Figure 5.64
Windows PowerShell ISE provides help with command syntax.
The Show-Command pane
The Show-Command pane (Figure 5.65) is another feature of the Windows
PowerShell ISE interface. The Show-Command add-on is displayed on the right
side of the PowerShell ISE window by default, but it can be enabled or disabled
through the interface’s View menu.
176
Understanding Hyper-V in Windows Server 2012
Figure 5.65
The Show-Command pane can help you to assemble PowerShell cmdlets.
As you enter a command, the Show-Command add-on displays various fields
that allow you to enter values to use with the command. For example, if you
were to enter the New-VM command, you could enter values such as the virtual
machine’s name and startup memory.
Once you have filled in the various attribute fields, you can use the buttons
at the bottom of the window to run the command, insert the command into
the PowerShell window or copy the command to the clipboard.
TechNet
Finally, Microsoft TechNet is a great resource for getting help with PowerShell
commands. The page is located at: http://technet.microsoft.com/en-us/library/
hh848559.aspx (Figure 5.66) and contains a full list of every available Hyper-Vrelated cmdlet. Clicking on a cmdlet takes you to a page that provides the full
syntax (Figure 5.67) and some usage examples for the cmdlet.
177
Understanding Hyper-V in Windows Server 2012
Figure 5.66
TechNet provides a reference for all of all of the Hyper-V related cmdlets.
Figure 5.67
Clicking on a link takes you to a page with the cmdlet’s syntax and usage examples.
178
Understanding Hyper-V in Windows Server 2012
About the Author
Brien Posey is a freelance technical writer who has
received Microsoft's MVP award 9 times for his work with
Exchange Server, Windows Server, IIS, and File Systems
Storage.
Brien has written or contributed to about three dozen
books, and has written well over 4,000 technical articles
and white papers for a variety of printed publications
and Web sites.
In addition to his writing, Brien routinely speaks at
IT conferences and is involved in a wide variety of other
technology related projects.
About Veeam Software
Veeam® Software develops innovative solutions for VMware backup, Hyper-V
backup, and virtualization management. Veeam Backup & Replication™ is
the #1 VM Backup solution. Veeam ONE™ is a single solution for real‑time
monitoring, resource optimization, documentation and management reporting
for VMware and Hyper-V. Veeam extends deep VMware monitoring to
Microsoft System Center with Veeam Management Pack™ (MP), and to HP
Operations Manager with Veeam Smart Plug-In™ (SPI). Veeam also provides free
virtualization tools. Learn more by visiting www.veeam.com.
179
Understanding Hyper-V in Windows Server 2012
NEW!
Veeam Backup & Replication™ v6
Extending the lead in VM backup with these new capabilities:
Enterprise scalability: new distributed architecture streamlines deployment
and maintenance of remote office/branch office (ROBO) and large installations.
Advanced replication: accelerates replication by 10x, streamlines failover,
and provides real failback with delta sync.
Multi-hypervisor support: brings Veeam’s award-winning data protection
to Microsoft Hyper-V and lets you protect all your VMs— VMware and Hyper-V—
from one console.
and more!
2010
Products
of the Year
GOLD
To learn more, visit
http://www.veeam.com/backup
180
Understanding
Hyper-V
in Windows Server 2012
Brien Posey
Pete Zerger, Chris Henley
Understanding Hyper-V in Windows Server 2012
Contents
Chapter 1. An Introduction to Hyper-V 3.0
Chapter 2. Failover Clustering
3
30
Chapter 3. Migrations 84
Chapter 4. Managing Virtual Machine Failover
123
Chapter 5. PowerShell Management
142
Coming soon:
Chapter 6. Virtual Machine Management
Chapter 7. P2V conversions
Chapter 8. Replication
Chapter 9. Hyper-V Management
Chapter 10. Networking
Chapter 11. Automation
Chapter 12. Backup
2
Understanding Hyper-V in Windows Server 2012
Chapter 1
An Introduction
to Hyper-V 3.0
This chapter is designed to get you started quickly with
Hyper-V 3.0. It starts with a discussion of the hardware
requirements for Hyper-V 3.0 and then explains a basic
Hyper-V–deployment followed by an upgrade from
Hyper-V 2.0 to Hyper-V 3.0. The chapter concludes with
a demonstration of migrating virtual machines from
Hyper-V 2.0 to Hyper-V 3.0
3
Understanding Hyper-V in Windows Server 2012
Hyper-V 3.0 flavors
Before we get started, it is worth noting that like its predecessors, Hyper-V
3.0 comes in two different flavors. Microsoft offers a standalone version
of Hyper-V, or you can operate Hyper-V as a server role on top of Windows
Server 2012. This book deals with Hyper-V exclusively as a server role.
Hardware requirements
According to Microsoft, the minimum hardware required for deploying
Windows Server 2012 includes:
• A 64-bit processor operating at 1.4 GHz or higher
• 512 MB of RAM
• 32 GB of hard disk space
• A DVD Drive
• A monitor and video card with a minimum display resolution of 800 x 600
• Keyboard and mouse (or other compatible pointing device)
• Internet access
Because Hyper-V is designed to use the server’s hardware to host a number
of virtual machines, the minimum system requirements are not suitable
for Hyper-V. Specifically, you will need more memory and hard disk space,
and it’s advisable to have a server with multiple sockets and/or multiple CPU
cores. The servers used in the development of this book were equipped with
the following:
• An 8-core, 64-bit CPU
• 32 GB of RAM
• A 500-GB hard drive used to store the host operating system.
• Four 1-TB hard drives configured as a RAID 5 array
In addition to the hardware requirements listed above, the CPU must support
hardware-level virtualization. It is worth noting that virtualization has been
disabled by default on many servers, so you may need to enable virtualization
through the system BIOS, as shown in Figure 1.1. If your server’s BIOS contains
a setting for Data Execution Prevention (DEP), you will need to enable that
setting as well.
4
Understanding Hyper-V in Windows Server 2012
Figure 1.1
You may need to manually enable virtualization in the server’s BIOS.
Installing Windows Server 2012
and Hyper-V 3.0
Setting up a clean installation of Windows Server 2012 and Hyper-V 3.0 is
relatively simple and straightforward. First, install Windows Server 2012 by
completing these steps:
1. Boot your server from the Windows Server 2012 installation media.
2. When the Windows Server 2012 splash screen launches, verify that
the language, time and currency format, and keyboard or input methods
are correct (Figure 1.2).
Figure 1.2
Verify your installation preferences.
5
Understanding Hyper-V in Windows Server 2012
3. Click Next.
4. Click Install Now (Figure 1.3).
Figure 1.3
Click Install Now.
5. Choose the operating system that you want to install (Figure 1.4). It is
worth noting that a default Windows Server 2012 does not include
the GUI. If you want to use the GUI then do not choose the Server
Core option. Although Server Core is Microsoft’s preferred method
for deploying Windows Server 2012, it is easier to manage Hyper-V
through a GUI. Therefore, the instructions found throughout this book
will assume that you are using the GUI. If you are interested in Server Core
deployments, see Chapter 5 for a discussion about managing Hyper-V
through Windows PowerShell.
Figure 1.4
Choose the edition of Windows Server 2012 that you want to install.
6
Understanding Hyper-V in Windows Server 2012
6. Accept the license agreement and click Next (Figure 1.5).
Figure 1.5
You must accept Microsoft’s license agreement.
7. When prompted for the type of installation you want to perform, choose
the option for Custom: Install Windows Only (advanced) (Figure 1.6).
Figure 1.6
Choose the option to perform a custom installation.
8. Choose the volume on which you want to install Windows and click Next
(Figure 1.7).
7
Understanding Hyper-V in Windows Server 2012
Figure 1.7
Select the drive or volume on which you want to install Windows Server 2012.
9. Setup will now begin the installation process (Figure 1.8). After
the Windows installation completes , you must work through a separate
process to install Hyper-V.
Figure 1.8
The installation process will now begin.
Deploying Hyper-V 3.0
After Windows Server 2012 is up and running, the next step is to install
the Hyper-V role. To do so, follow these steps:
1. Open the Server Manager if it is not already open.
2. Choose the Add Roles and Features command from the Manage menu
(Figure 1.9).
8
Understanding Hyper-V in Windows Server 2012
Figure 1.9
Choose the Add Roles and Features command.
3. When the Add Roles and Features Wizard launches, click Next to bypass
the wizard’s Welcome screen.
4. Click Next.
5. Choose the Role-Based or Feature-Based Installation option (Figure 1.10).
Figure 1.10
Choose the Role Based or Feature Based Installation option.
6. Click Next.
7. On the Server Selection screen, make sure that the local server is selected
and click Next (Figure 1.11).
9
Understanding Hyper-V in Windows Server 2012
Figure 1.11
Make sure that your local server is selected.
8. Select Hyper-V from the list of server roles (Figure 1.12).
Figure 1.12
Select the Hyper-V role.
9. If you are prompted to install additional features, click the Add
Features button.
10. Click Next.
10
Understanding Hyper-V in Windows Server 2012
11. When the wizard displays the list of available features, click Next.
12. Click Next on the Hyper-V introductory screen.
13. Select the network adapters that you want to make available to your
virtual machines. Be sure to reserve at least one network adapter for host
management traffic (Figure 1.13).
Figure 1.13
Be sure to reserve a network adapter for host management traffic.
14. Click Next.
15. At this point you will see a screen asking if you want to allow the server to
send and receive live migrations of virtual machines. Live migrations are
discussed in Chapter 3, so for now just click Next to accept the defaults.
16. When prompted, click Next to accept the default stores.
17. When the Confirmation screen is displayed, click the Install button.
Post deployment tasks
After the installation process completes, you may need to perform a number of
post-deployment tasks, which might include:
• Configure the host’s IP address
• Rename the host
• Join the host to a domain
The sections that follow will walk you through performing each of these tasks.
11
Understanding Hyper-V in Windows Server 2012
Configure the host’s IP address
In most cases, Hyper-V host servers need to have at least one NIC that is
dedicated to hosting management traffic. As a best practice, you should assign
a static IP address to this NIC. You can assign an IP address to the server’s
management NIC as follows:
1. Move the mouse to the lower left corner of the screen and right click.
Choose the Control Panel option from the right-click menu.
2. When the Control Panel appears, click on Network and Internet.
3. Click on Network and Sharing Center.
4. Click on the Change Adapter Settings link.
5. Right click on the icon representing your management NIC and choose
the Properties command from the shortcut menu.
6. Assuming that IPv4 is being used, select the Internet Protocol Version 4
(TCP/IPv4) option and click the Properties button (Figure 1.14).
7. Enter the IP address that you want to assign to the NIC and click OK
(Figure 1.15).
Figure 1.14
Select Internet Protocol Version 4 (TCP/IPv4) and click the Properties button.
12
Understanding Hyper-V in Windows Server 2012
Figure 1.15
Provision your management NIC with a static IP address and click OK.
Rename the host
Windows Server 2012 automatically assigns a unique host name to each server,
but it is generally advisable to assign a more meaningful name to each Hyper-V
host. Doing so will make the host management process easier. To assign a new
name to your Hyper-V host server, follow these steps:
1. M
ove the mouse to the lower left corner of the screen and right click.
Choose the System option from the right-click menu.
2. When the System properties sheet appears, click on the Change Settings
link (Figure 1.16).
13
Understanding Hyper-V in Windows Server 2012
Figure 1.16
Click the Change Settings link.
3. Verify that the Computer Name tab is selected and then click the Change
button (Figure 1.17).
Figure 1.17
Click the Change button.
14
Understanding Hyper-V in Windows Server 2012
4. Enter a new name for the server and click OK (Figure 1.18).
Figure 1.18
Enter a new computer name and click OK.
5. Click OK to acknowledge the message indicating that you must restart
your computer to apply the new name.
6. Click Close.
7. When prompted, click Restart Now (Figure 1.19).
Figure 1.19
You must restart the server before your changes will take effect.
15
Understanding Hyper-V in Windows Server 2012
Join the host to a domain
The process of joining a Windows Server 2012 host to a domain is very similar
to that used in joining a Windows Server 2008 R2 host to a domain. To join
a domain, follow these steps:
1. From the Metro interface, click the Desktop tile.
2. Move your mouse to the lower left corner of the screen and right-click on
the Start tile.
3. Click on the System option on the right-click menu.
4. When the System dialog box appears, click on the Change Settings link
(Figure 1.16).
5. When the System Properties sheet appears, go to the Computer Name
tab and click the Change button (Figure 1.17).
6. Select the Domain option and enter the fully qualified domain name
(Figure 1.18).
7. Click OK.
8. When prompted, enter a set of administrative credentials for the domain.
9. Click OK to clear the message indicating that the computer has been
joined to a domain.
10. Reboot the server (Figure 1.19).
Performing an in-place upgrade from
Hyper-V 2.0
If your organization is currently running Hyper-V 2.0, it is usually possible to
perform an in-place upgrade to Hyper-V 3.0. In preparation for an upgrading
a standalone Hyper-V 2.0 server, you must shut down any virtual machines that
are currently running. To complete the upgrade, follow these steps:
1. Shut down any virtual machines that are running on the server to be
upgraded. If any virtual machines are left running, the Compatibility
Report will prevent the upgrade from continuing (Figure 1.20).
16
Understanding Hyper-V in Windows Server 2012
Figure 1.20
You must shut down the virtual machines prior to beginning the upgrade.
2. With Windows Server 2008 R2 still running, insert your Windows Server
2012 installation media and run the Setup program.
3. When the Windows Server 2012 splash screen appears, click Install Now
(Figure 1.21).
Figure 1.21
Click the Install Now button.
4. When prompted, click on the option to go online to install updates
(Figure 1.22).
17
Understanding Hyper-V in Windows Server 2012
Figure 1.22
You should go online to get the latest updates.
5. Enter your product key and click Next.
6. Select whether you want to perform a server core deployment or a fullserver deployment that includes the GUI (Figure 1.23). It is worth
noting that Windows Server 2012 is designed to perform a server
core deployment by default. However, you cannot perform an in-place
upgrade of a full Windows Server deployment (with a GUI) to a server
core deployment. If you want a server core deployment, you will have to
upgrade to the full GUI version of Windows Server 2012 and then uninstall
the GUI later. The instructions provided in this book assume that you will
be working with a full GUI-based installation. If you are interested in using
Server Core, see Chapter 5 for a discussion of how to manage Hyper-V
from PowerShell.
Figure 1.23
Choose the edition of Windows Server 2012 that you want to install.
18
Understanding Hyper-V in Windows Server 2012
7. Click Next.
8. When prompted, accept the license agreement and click Next
(Figure 1.24).
Figure 1.24
You must accept Microsoft’s license agreement.
9. Choose the option to Upgrade: Install Windows and keep files, settings,
and applications (Figure 1.25).
Figure 1.25
Choose the option to upgrade the existing operating system.
10. Take a moment to review the Compatibility Report, which informs you
of issues you need to address prior to moving forward with the upgrade
(Figure 1.26). When you are finished, click Next.
19
Understanding Hyper-V in Windows Server 2012
Figure 1.26
Take a moment to read the compatibility report.
11. At this point, Windows will be installed. The remainder of the upgrade
process is automated.
Migrating virtual machines from Hyper-V
2.0 to Hyper-V 3.0
One of the big disadvantages to performing an in-place upgrade is that it can
cause virtual machines to be down for a significant amount of time. One way
to reduce the amount of time during which virtual machines are unavailable
is to perform a migration rather than an upgrade. A migration involves
deploying Hyper-V 3.0 onto new hardware while your existing hardware
continues to run Hyper-V 2.0. Once the deployment is complete, you can
migrate the individual virtual machines from the Hyper-V 2.0 deployment to
the Hyper-V 3.0 deployment.
Exporting the virtual machines
The first step in migrating virtual machines from Hyper-V 2 to Hyper-V 3 is to
export the virtual machines to either a network share or to removable media.
To complete the export process, follow these steps:
1. Open the Hyper-V Manager on the Hyper-V 2.0 Server.
2. Select the virtual machines that you want to export (Figure 1.27).
20
Understanding Hyper-V in Windows Server 2012
Figure 1.27
Select the virtual machines that you wish to export.
3. Click on the Export link.
4. Specify a path to write the exported content (Figure 1.28). Be sure to
choose a location with plenty of free storage space.
Figure 1.28
Enter an export path and click the Export button.
5. Click Export.
You can monitor the progress of the export by scrolling the Hyper-V Manager
to view the virtual machine Status (Figure 1.29).
21
Understanding Hyper-V in Windows Server 2012
Figure 1.29
You can monitor the export process through the Hyper-V Manager.
Importing virtual machines
Importing virtual machines into Hyper-V 3.0 is a relatively easy
and straightforward process. You can import one or more virtual machines
as follows:
1. Open the Hyper-V Manager.
2. Right-click on the name of the Hyper-V host and select the Import Virtual
Machine command from the right-click menu (Figure 1.30).
Figure 1.30
Right click-on your the server and select the Import Virtual Machine command from
the right‑click menu.
3. When the Import Virtual Machine wizard launches, click Next to bypass
the wizard’s Welcome screen.
4. Click the Browse button.
22
Understanding Hyper-V in Windows Server 2012
5. Navigate to the folder containing the virtual machine that you want to
import and click the Select Folder button.
6. Choose the virtual machine that you want to import (Figure 1.31).
Figure 1.31
Select the virtual machine that you want to import.
7. Click Next.
8. The next screen asks you to choose an import type (Figure 1.32). Unless
you have a compelling reason to choose one of the other options, it is
usually best to choose the option to Copy the Virtual Machine (Create
a New Unique ID). This allows the exported virtual machine to be
re‑imported later should the need ever arise.
23
Understanding Hyper-V in Windows Server 2012
Figure 1.32
Choose the appropriate import type.
9. Click Next.
10. The following screen asks if you want to store any of the virtual machine
components in a different location. Generally, it is safe to accept
the defaults. Click Next.
11. The wizard will now ask where you want to store the imported Virtual
Hard Disks. Select a folder on an appropriate volume and click Next.
12. Verify the summary information screen and click Finish (Figure 1.33).
24
Understanding Hyper-V in Windows Server 2012
Figure 1.33
The import process begins when you click Finish.
The import process can take a considerable amount of time to complete,
depending upon the size of the virtual machine and the speed of the hardware.
When the import process finishes, you should see the newly imported virtual
machine within the Hyper-V Manager.
Before you power-up the newly imported virtual machine, you need to connect
the virtual machine to a virtual switch. To do so, right click on the virtual
machine and choose the Settings command from the right-click menu. When
the Settings page appears, click on the Network Adapter option and then
connect the virtual machine to the appropriate virtual switch (Figure 1.34).
When you have finished, click OK.
25
Understanding Hyper-V in Windows Server 2012
Figure 1.34
You must connect your virtual machine to a virtual switch.
This completes the process of importing a virtual machine. Previous versions
of Hyper-V required you to re-enter the IP address configuration for each
virtual network adapter. However, Hyper-V 3.0 preserves the virtual machine’s
IP address configuration. The only change that you might need to make to
the virtual machine is to install an updated version of the Hyper-V Integration
Services.
What about clusters?
This chapter has discussed clean Hyper-V installations as well as the process
for upgrading a Hyper-V 2.0 server to Hyper-V 3.0. Although these techniques
are certainly valid, organizations that are currently running Hyper-V are often
using a clustered environment.
The process of building a Hyper-V cluster is discussed in detail in Chapter 2. This
section explains what is involved in upgrading a Hyper-V 2.0 cluster to Hyper-V
3.0—a process that is not entirely intuitive.
Microsoft’s preferred method for performing a cluster upgrade involves building
an entirely new cluster. The basic idea is to create a cluster out of servers that are
running Windows Server 2012. If you lack the budget to build a completely new
cluster, you can start small by building the new cluster with a minimum number
of cluster nodes and using low-end hardware if necessary. After the migration
26
Understanding Hyper-V in Windows Server 2012
process is complete, you can always install Windows Server 2012 onto your
existing cluster hardware, join those servers to the new cluster and then remove
the temporary, low-end servers from the cluster. Don’t worry too much about
exceeding the maximum cluster size during the migration process, because
Windows Server 2012 allows up to 63 cluster nodes.
As you probably know, Hyper-V 2.0 clusters depend on the use of Cluster Shared
Volumes. When you build the new Hyper-V 3.0 cluster, you must attach the
cluster nodes to the existing cluster shared volume (see Chapter 2 for details).
At this point, both the Hyper-V 2.0 cluster and the Hyper-V 3.0 cluster should be
tied into the same Cluster Shared Volume.
Once the Hyper-V 3.0 cluster is in place, verify that the Hyper-V 2.0 cluster is
still functional and that the virtual machines are still running (there is no reason
why they shouldn’t be, because the cluster has not been modified). Now, open
the Failover Cluster Manager on one of your Windows Server 2012 servers
and follow these steps:
1. Right-click on the cluster name and choose the More Actions | Migrate
Roles commands from the right-click menus (Figure 1.35).
Figure 1.35
Choose the Migrate Roles option.
2. When the Migrate a Cluster Wizard launches, click Next to bypass
the wizards’ Welcome screen.
3. When prompted, enter the name of the old cluster from which you plan to
migrate the virtual machines (Figure 1.36).
27
Understanding Hyper-V in Windows Server 2012
Figure 1.36
Enter the name of your Hyper-V 2.0 cluster.
4. Select the virtual machines that you plan to migrate and click Next
(Figure 1.37).
Figure 1.37
Choose the virtual machines that you want to migrate.
5. Choose the Virtual Network Switch that the virtual machines should use
after they have been migrated to the new cluster and click Next.
28
Understanding Hyper-V in Windows Server 2012
6. The next screen provides an analysis of the migration. You can click
the View Report button to see the full Failover Cluster Pre-Migration
Report. It is worth noting that the report indicates that the cluster group
and the available storage cannot be migrated. This is perfectly normal
and acceptable.
7. Close the report and click Next.
8. Take a moment to verify the information displayed on the Confirmation
screen and click Next.
9. When the migration completes, click Finish.
Please keep in mind that Windows Server 2012 does not perform a live migration
of the virtual machines. When the migration completes, the virtual machines are
still running on the Hyper-V 2.0 cluster, so there are a couple of things that you
need to do to complete the process.
First, shut down the virtual machines on the Hyper-V 2.0 server. Second,
disconnect the Hyper-V 2.0 cluster nodes from the shared storage. If you fail to
do this, virtual machine corruption can occur. Finally, start the virtual machines
on your new cluster. Once the virtual machines are up and running, it is safe to
destroy your Hyper-V 2.0 cluster and re-provision the host servers for use in
the new cluster.
29
Understanding Hyper-V in Windows Server 2012
Chapter 2
Failover Clustering
Chapter 2 is designed to familiarize you with your options
for Hyper-V clustering. Hyper-V 3.0 allows you to build
a cluster with or without shared storage, and this chapter
walks you through both methods. In addition, you will
learn how to provision storage using a new Windows
Server 2012 feature called Windows Storage Spaces.
30
Understanding Hyper-V in Windows Server 2012
Perhaps the most important concept to understand with regard to server
virtualization is that of clustering. The reason for this is simple: Server
virtualization places an increased importance on server hardware. In a traditional
physical datacenter the failure of a single server is typically regarded as
an inconvenience, but is rarely catastrophic. In a virtual datacenter, however,
this may not be the case. Each physical server hosts multiple virtual machines.
Therefore, if a physical server fails then all of the virtual machines residing on that
server will also fail. Hence, the failure of a single physical host can cause a major
outage. The only way to protect against this type of failure is through the use of
failover clustering.
Failover clustering spreads a virtualized workload across multiple physical hosts.
That way if a host server fails, the virtual machines can fail over to a different host
server within the cluster and remain online in spite of the failure.
Failover clustering is not new to Hyper-V 3.0, but Microsoft has made significant
improvements to failover clustering. Many of these improvements are related
to scalability. The table below compares a Hyper-V 2.0 cluster to a Hyper-V 3.0
cluster in terms of scalability.
Hyper-V 2.0
Hyper-V 3.0
384
1024
Maximum number of
virtual machines in
a cluster
1000
4000
Maximum number of
hosts per cluster
16
63
1 TB
2 TB
The maximum number of
virtual machines per host
that can be powered on at
any given time
Maximum RAM per
host server
Another major improvement that Microsoft has made with regard to failover
clustering is that they have changed the storage requirements. Prior to Hyper-V
3.0, a Hyper-V cluster depended on the use of a Cluster Shared Volume.
A Cluster Shared Volume is a shared storage volume that physically contains all
of the virtual machine components. Because the storage is shared, it is physically
accessible to all of the cluster nodes. You can see an example of shared storage
architecture in Figure 2.1.
31
Understanding Hyper-V in Windows Server 2012
Figure 2.1
Previous versions of Hyper-V required failover clusters to make use of shared storage.
In Hyper-V 3.0, shared storage is no longer required for failover clustering.
A failover cluster can be built without the need for a Cluster Shared Volume.
In those types of clusters, the virtual machines can reside on local direct
attached storage or they can even reside on certain types of file servers.
The fact that you can create failover clusters without a Cluster Shared Volume is
good news for smaller organizations because the cost of shared storage often
puts clustered virtualization hosts financially out of reach. Even so, Microsoft
recommends that Hyper-V 3.0 failover clusters make use of failover clusters
whenever possible . This chapter will demonstrate the process of building
failover clusters both with and without shared storage.
Cluster planning
Before you begin constructing a failover cluster you will need to do some
planning. Obviously you will need to decide whether the cluster will
use shared storage, you’ll need to take into account a number of other
considerations, including:
• Domain membership — Domain membership isn’t an absolute
requirement for cluster nodes, but the configuration process is a lot easier
if all of the cluster nodes are members of a common Active Directory
domain. Domain membership allows Kerberos authentication to be
used. This chapter will assume that all cluster nodes have been joined
to a common Active Directory domain.
• Node names — Just as the cluster requires a cluster name, each cluster
node requires a unique computer name. Although Windows Server 2012
assigns computer names automatically, it is highly recommended that you
assign computer names that are more descriptive. Doing so makes it easier
to figure out which node you are working on. The cluster nodes used in
the examples in this chapter will be named Lab1, Lab2 and Lab3.
32
Understanding Hyper-V in Windows Server 2012
• Cluster name — The configuration process requires that a unique name
be assigned to the cluster. The name you choose should be different from
any of the computer names that are used within your Active Directory.
• Cluster node hardware — Another important consideration is the cluster
nodes themselves. The nodes do not have to use identical hardware, but
they should all use the same CPU architecture and ideally they should be
equipped with comparable amounts of memory.
• Number of nodes — You also need to decide how many nodes to use
in your cluster. In this chapter you will be building a Majority Node Set
Cluster. It is best to use an odd number of cluster nodes whenever possible
because a Majority Node Set Cluster requires half of the nodes plus one
to remain online during a failure in order for the cluster to retain quorum.
It is technically possible to build a failover cluster out of two cluster nodes
(plus a file share witness), but it's recommended that you always use at
least three cluster nodes. Your cluster can contain as many as 63 nodes.
Of course, most clusters use far fewer than 63 nodes, and you always have
the option of adding additional cluster nodes later until the maximum
number of nodes has been reached.
• Network adapters — Hyper-V is very flexible in terms of the network
adapter requirements for cluster nodes. However, it is generally
recommended that each cluster node have a minimum of three network
adapters. You should reserve one adapter should be reserved for
management traffic and another adapter for cluster traffic. The third
(and any additional adapters) are used for virtual machine traffic.
• Node IP addresses — As a best practice, you should assign a static IP
address to each cluster node’s management NIC. However, you will also
need to decide how you want to handle IP address assignment for the
other NICs.
• Cluster IP address — In addition to the IP addresses assigned to physical
NICs you must assign a static IP address to the cluster. This IP address
is used to communicate with the cluster as a whole rather than with
an individual cluster node.
Building a failover cluster without
shared storage
As previously mentioned, it is possible to build a failover cluster without using
shared storage. This part of the chapter will walk you through the process. You
will be building a Majority Node Set cluster consisting of three cluster nodes.
Keep in mind, however, that if it is within your budget, you should use shared
storage whenever possible, as Microsoft recommends.
This section assumes that you have installed Windows Server 2012
onto each cluster node, joined the cluster nodes to an Active Directory
domain, and provisioned each node with an appropriate computer name
and the necessary IP addresses.
33
Understanding Hyper-V in Windows Server 2012
Installing the failover clustering feature
The first step in the configuration process is to install the Failover Clustering
feature onto each cluster node. You can accomplish this task by following
these steps:
1. Open the Server Manager
2. Choose the Add Roles and Features option from the Manage menu.
3. When the Add Roles and Features Wizard starts, click Next to bypass
the welcome screen.
4. Choose the Role-Based or Feature-Based Installation option and click
Next.
5. Verify that the correct server is selectedand click Next (Figure 2.2).
Figure 2.2
You must install the Failover Clustering feature onto each of the cluster nodes.
6. When the wizard displays the list of server roles, click Next.
7. Select Failover Clustering from the list of features (Figure 2.3). If the wizard
prompts you to install additional features, click the Add Features button.
34
Understanding Hyper-V in Windows Server 2012
Figure 2.3
Select the Failover Clustering feature.
8. Click Next.
9. Click Install.
10. When the installation process completes, click Close.
Building a Majority Node Set Cluster
Now that the Failover Clustering Service has been installed, the next step in
the process is to build the failover cluster. The steps listed in this section only
need to be performed on one of the cluster nodes. To create the failover cluster,
follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, click on the Create Cluster link,
found in the Actions pane (Figure 2.4). Windows will launch the Create
Cluster Wizard.
35
Understanding Hyper-V in Windows Server 2012
Figure 2.4
Click on the Create Cluster link.
4. Click Next to bypass the wizard’s Welcome screen.
5. Specify the names of the servers that you want to include in the cluster
(Figure 2.5).
Figure 2.5
You should specify all of the nodes that you want to include in the cluster.
36
Understanding Hyper-V in Windows Server 2012
6. Click Next.
7. You should now see a message indicating that the cluster has not yet been
validated. Choose the option to run the validation tests and click Next
(Figure 2.6). Windows will launch the Validate a Cluster Wizard.
Figure 2.6
You must validate the cluster before you can create it.
8. Click Next to bypass the wizard’s Welcome screen.
9. Choose the Run All Tests (Recommended) option and click Next.
10. Click Next to begin the validation tests.
11. When the validation tests complete, take a moment to view the report
and review any errors or warnings (Figure 2.7). Click Finish.
37
Understanding Hyper-V in Windows Server 2012
Figure 2.7
Review the validation report and check for any errors or warnings.
12. When prompted, enter a name for the cluster and assign an IP address
to the cluster (Figure 2.8). The name and IP address that you use should be
unique and will be used to identify the cluster as a whole.
Figure 2.8
You must assign a unique name and static IP address to the cluster.
38
Understanding Hyper-V in Windows Server 2012
13. Click Next.
14. Take a moment to verify the information presented on the confirmation
screen and click Next.
15. You should see a message indicating that the cluster was created
successfully. Click Finish to close the wizard.
Installing the Hyper-V role
The next step in the process is to install the Hyper-V role. This role must be
installed onto each of the cluster nodes. To complete this process, follow
these steps:
1. Open the Server Manager.
2. Choose the Add Roles and Features command from the Manage menu.
3. When the Add Roles and Features wizard appears, click Next to bypass
the wizard’s Welcome screen.
4. Make sure that the Role-Based or Feature-Based Installation option is
selected and click Next.
5. Select the server on which you want to deploy the Hyper-V role and click
Next (Figure 2.9).
Figure 2.9
Choose the server on which you want to deploy the Hyper-V role.
39
Understanding Hyper-V in Windows Server 2012
6. Select the Hyper-V option from the list of roles (Figure 2.10).
Figure 2.10
Select the Hyper-V role and click Next.
7. If you are prompted to add additional features, click the Add Features
button.
8. Click Next.
9. Click Next.
10. Click Next.
11. Select the network adapters that you want to connect to the virtual
switch (Figure 2.11). You can select multiple network adapters, but as
a best practice you should reserve a network adapter for management
traffic and reserve an adapter for cluster communications (such as cluster
heartbeats and live migration traffic).
40
Understanding Hyper-V in Windows Server 2012
Figure 2.11
Select the network adapters that you want to connect to the Hyper-V virtual switch.
12. Click Next.
13. Select the checkbox for Allow this Server to Send and Receive Live
Migrations of Virtual Machines (Figure 2.12).
Figure 2.12
Cluster nodes must be able to live migrate virtual machines.
41
Understanding Hyper-V in Windows Server 2012
14. Select the authentication protocol to be used by live migration traffic. If
the cluster nodes reside in the same Active Directory domain, then you
should use the Kerberos protocol. Kerberos is more secure than CredSSP
and the configuration process is easier.
15. Click Next.
16. Click Next to accept the default store location.
17. Take a moment to verify the information that is displayed on
the Confirmation screen and then click Install.
18. When the installation process completes, click Close and then reboot
the server.
19. Repeat these steps for each node in the cluster.
Making Hyper-V fault tolerant
So far you have installed the Failover Clustering feature and the Hyper-V role.
Even so, Hyper-V is not yet fault tolerant. Fault tolerance is implemented on
a per-virtual-machine basis. That being the case, it’s a good idea to create
some virtual machines. Then you can make your virtual machines fault tolerant
by following these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager from the list of tools.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster name> | Roles
(Figure 2.13).
Figure 2.13
Navigate through the Failover Cluster Manager to Failover Cluster Manager | <your cluster
name> | Roles.
4. Click the Configure Role link, found in the Actions pane.
5. Windows will launch the High Availability Wizard. Click Next to bypass
the wizard’s Welcome screen.
6. The next screen lists a variety of server roles. Select the Virtual Machine
role from the list and click Next (Figure 2.14).
42
Understanding Hyper-V in Windows Server 2012
Figure 2.14
Select the Virtual Machine option and click Next.
7. Select the virtual machines that you wish to make fault tolerant and click
Next (Figure 2.15).
Figure 2.15
Select the virtual machines that you wish to make fault tolerant and click Next.
43
Understanding Hyper-V in Windows Server 2012
8. Verify the information displayed on the confirmation screen and click Next.
9. When the process completes you should see a message confirming that
high availability was successfully configured. Click the View Report button
to examine the report. Click Finish.
After the virtual machines become fault tolerant, you should see them listed
in the Failover Cluster Manager’s Roles container (Figure 2.16). Likewise,
the Hyper-V Manager should list the virtual machine as being clustered
(Figure 2.17).
Figure 2.16
The virtual machine should now be listed in the Failover Cluster Manager.
Figure 2.17
The Hyper-V Manager should list the virtual machine as being clustered.
44
Understanding Hyper-V in Windows Server 2012
Building a failover cluster using
shared storage
Even though you can build a Hyper-V 3.0 cluster without the need for shared
storage, Microsoft’s preferred method for building a Hyper-V failover cluster
still involves the use of a Cluster Shared Volume. In this section you will learn
how to build a majority node set cluster consisting of three cluster nodes
and a fourth server that hosts the Cluster Shared Volume for the cluster.
This section assumes that you have installed Windows Server 2012
onto each cluster node, joined the cluster nodes to an Active Directory
domain, and provisioned each node with an appropriate computer name
and the necessary IP addresses.
The method or building a failover cluster that utilizes shared storage is
similar to that used for a shared nothing cluster. Even so, this section will walk
you through the procedure in its entirety (including procedures that were
demonstrated in the previous section) because the procedures have to be
performed in a certain order.
Installing the Failover Clustering feature
The first step in the configuration process is to install the Failover Clustering
feature onto each cluster node. You can accomplish this task by following
these steps:
1. Open Server Manager
2. Choose the Add Roles and Features option from the Manage menu.
3. When the Add Roles and Features Wizard starts, click Next to bypass
the welcome screen.
4. Choose the Role-Based or Feature-Based Installation option
and click Next.
5. Verify that the correct server is selected and click Next.
6. When the wizard displays the list of server roles, click Next.
7. Select Failover Clustering from the list of features (Figure 2.18).
If the wizard prompts you to install additional features, click the Add
Features button.
45
Understanding Hyper-V in Windows Server 2012
Figure 2.18
Select the Failover Clustering feature and click Next.
8. Click Next.
9. Click Install.
10. When the installation process completes, click Close.
Building a Majority Node Set Cluster
Now that the Failover Clustering feature has been installed, it is time to create
the cluster. Once again, you will be creating a Majority Node Set Cluster
consisting of three cluster nodes. It is only necessary to perform the procedure
below on a single cluster node. To create the cluster, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, click on the Create Cluster link,
found in the Actions pane. When you do, Windows will launch the Create
Cluster Wizard.
4. Click Next to bypass the wizard’s Welcome screen.
5. Specify the names of the servers that you want to include in the cluster
(Figure 2.19).
46
Understanding Hyper-V in Windows Server 2012
Figure 2.19
Specify the names of the servers that will make up the cluster.
6. Click Next.
7. You should now see a message indicating that the cluster has not yet
been validated. Choose the option to run the validation tests and click
Next (Figure 2.20). This will cause Windows to launch the Validate
a Cluster Wizard.
Figure 2.20
The cluster must be validated.
47
Understanding Hyper-V in Windows Server 2012
8. Click Next to bypass the wizard’s Welcome screen.
9. Choose the Run All Tests (Recommended) option and click Next
(Figure 2.21).
Figure 2.21
You must run all of the validation tests.
10. Click Next to begin the validation tests.
11. When the validation tests complete, take a moment to view the report
and review any errors or warnings (Figure 2.22). Click Finish.
48
Understanding Hyper-V in Windows Server 2012
Figure 2.22
Review the validation report for any errors or warnings.
12. When prompted, enter a name for the cluster and assign an IP address
to the cluster (Figure 2.23). The name and IP address that you use should
be unique and will be used to identify the cluster as a whole.
Figure 2.23
Specify the name and IP address to be used by the cluster.
49
Understanding Hyper-V in Windows Server 2012
13. Click Next.
14. Take a moment to verify the information presented on the confirmation
screen and click Next.
15. You should now see a message indicating that the cluster was created
successfully (Figure 2.24). Click Finish to close the wizard.
Figure 2.24
Verify that the cluster has been created successfully.
Shared storage
In the past if you wanted to use failover clustering with Hyper-V, you had to
make use of shared storage in the form of a Cluster Shared Volume. Although
Hyper-V 3.0 does not require a Cluster Shared Volume for clustering, shared
storage is still the preferred method for building a failover cluster.
As has always been the case, you can create a Cluster Shared Volume on
virtually any iSCSI or Fibre Channel accessible storage device. This can include
a SAN, a physical NAS appliance or even a server that is configured to act as
a shared storage device. The actual method you use to provision the shared
storage varies depending on the physical hardware you are using.
For the sake of demonstration, this example will use a Windows Server to
host the shared storage and will connect to this server using iSCSI. This server
contains four physical hard disks. The first hard disk is a 250-GB disk that
contains the Windows Server 2012 operating system files. The remaining
three hard disks are each 500 GB in size and will be configured to act as
a RAID 5 array. Keep in mind that this configuration is only being used for
demonstration purposes. Real-world organizations typically use larger arrays
and those arrays are often configured as RAID 6 or as RAID 10, because
such RAID configurations are resistant to the failures of multiple drives.
For this demonstration, however, RAID 5 will work within the limitations of
the lab hardware.
50
Understanding Hyper-V in Windows Server 2012
There are two ways to create the necessary storage array. The legacy method,
which will be discussed first, is the one you will have to use this method if
your shared storage resides on an older version of Windows Server. The other
method is the preferred method of storage provisioning in Windows Server
2012, which will be discussed second.
Legacy storage provisioning
The first technique describes how to create a storage array using the Windows
Disk Management Console. You will have to use if you are hosting the storage
on an older version of Windows Server. This method works for Windows
Server 2012 as well, but Microsoft prefers that you use a newer method called
Storage Spaces.
To use the Disk Management Console to create a RAID 5 array, follow
these steps:
1. G
o to the server’s Run prompt and enter the DISKMGMT.MSC command.
This will cause Windows to open the Disk Management Console
(Figure 2.25). Notice in the figure that Disk 1, Disk 2 and Disk 3 are of
equal size; all are online and contain no partitions. If you need to bring
a disk online, right-click on the disk and choose the Online command from
the right-click menu.
Figure 2.25
The Disk Management Console lists all of the server’s physical disks.
51
Understanding Hyper-V in Windows Server 2012
2. Right-click on one of the empty disks and choose the New RAID 5 volume
command from the right-click menu (Figure 2.26). Windows will launch
the New RAID 5 Volume Wizard.
Figure 2.26
Choose the New RAID-5 Volume command.
3. Click Next to bypass the wizard’s Welcome screen.
4. Select the disk that you wish to add to the volume and click Add
(Figure 2.27). Repeat this step for any additional disks that you wish to add
to the new RAID 5 volume.
Figure 2.27
Add the physical disks to the RAID 5 volume.
52
Understanding Hyper-V in Windows Server 2012
5. Click Next.
6. Select the drive letter that you wish to assign to the volume that you are
creating (Figure 2.28).
Figure 2.28
Assign a drive letter to the volume that you are creating.
7. Click Next.
8. On the following screen choose the file system that you wish to use on the
new volume and decide whether to perform a quick format (Figure 2.29).
Figure 2.29
Choose a file system and format the new volume.
53
Understanding Hyper-V in Windows Server 2012
9. Click Next.
10. Click Finish.
11. A warning message tells you that the operation will convert the basic disks
to dynamic disks (Figure 2.30). Click Yes to continue.
Figure 2.30
The disks used in the array will be converted to dynamic disks.
12. After a brief delay Windows will format and synchronize the new volume.
Depending on the size of the disks that you are using, the synchronization
process can take a considerable amount of time to complete.
13. When the synchronization process completes, the new volume should be
displayed as Healthy (Figure 2.31).
Figure 2.31
The new volume should eventually be listed as healthy.
54
Understanding Hyper-V in Windows Server 2012
Using Windows Storage Spaces
As previously mentioned, using the Disk Management Console to provision
a storage array will work in Windows Server 2012, but that method is primarily
suited for volumes that are stored on legacy versions of Windows Server. If
a storage volume is stored on Windows Server 2012, Microsoft recommends
using a new feature called Windows Storage Spaces. The main benefits to using
Windows Storage Spaces instead of the Disk Management Console include:
• Volumes created using Windows Storage Spaces can be thin provisioned.
• You can add additional physical disk space as needed.
• You can choose the type of redundancy that is most beneficial.
• Storage resources can be provisioned much more quickly than they can
through the Disk Management Console.
Creating a storage pool
The first step in the process of configuring Windows Storage Spaces is to create
a storage pool. A storage pool is a collection of physical disks that act as a pool
of storage resources. You can create a storage pool by completing these steps:
1. Open the Server Manager.
2. Click on the File and Storage Services option, found in the console tree.
3. Click on Disks to verify that all of the server’s disks are displayed within
the console (Figure 2.32).
Figure 2.32
Click on the Disks container.
4. Click on Storage Pools (Figure 2.33).
55
Understanding Hyper-V in Windows Server 2012
Figure 2.33
The Primordial pool is created by default, but you will have to manually create all other
storage pools.
5. Choose the New Storage Pool option from the Task list.
6. When the New Storage Pool Wizard begins, click Next to bypass
the wizard’s Welcome screen.
7. Enter a name and an optional description of the storage pool that you
are creating.
8. Click Next.
9. Choose the disks that you wish to include within the storage pool
(Figure 2.34).
Figure 2.34
Choose the disks that you wish to include in the storage pool.
56
Understanding Hyper-V in Windows Server 2012
10. Use the Allocation drop down for each disk to control whether the disk
should be allocated as a data store, a hot spare, or a manual allocation
(Figure 2.35).
Figure 2.35
Specify the allocation for each disk in the storage pool.
11. Click Next.
12. Click Create.
13. When the storage pool has been created, click Close (Figure 2.36).
Figure 2.36
Verify that the storage pool has been created successfully.
57
Understanding Hyper-V in Windows Server 2012
You should now see the storage pool listed in the console along with
the physical disks that make up the storage pool (Figure 2.37).
Figure 2.37
The completed storage pool should look like this.
Creating a virtual disk
After the storage pool is created, the next step is to create a virtual disk within
the storage pool. This virtual disk will act as a repository for the virtual machine
components that will be stored within the Cluster Shared Volume. To create
the virtual disk, follow these steps:
1. Open the Server Manager if it is not already open.
2. Click on the File and Storage Services option, found in the console tree.
3. Click on the To Create a Virtual Disk, Start the New Virtual Disk
Wizard link.
4. When the New Virtual Disk Wizard starts, click Next to bypass
the Welcome screen.
5. Select your storage pool from the list and click Next (Figure 2.38).
58
Understanding Hyper-V in Windows Server 2012
Figure 2.38
Select your storage pool and click Next.
6. Enter a name and an optional description for the virtual disk.
7. Click Next.
8. Choose whether you want to configure a simple virtual disk or have
the virtual disk be mirrored or use parity (Figure 2.39).
Figure 2.39
Choose the method Windows will use to protect your virtual disk.
59
Understanding Hyper-V in Windows Server 2012
9. Click Next.
10. Choose whether you want to thinly provision the Virtual Hard Disk or
create a disk of a fixed size (Figure 2.40). Fixed size provisioning delivers
better performance, but thin provisioning is more flexible and makes more
efficient use of storage space.
Figure 2.40
Choose the provisioning type.
11. Enter the size of the Virtual Hard Disk that you want to create (Figure 2.41).
60
Understanding Hyper-V in Windows Server 2012
Figure 2.41
Specify the size of your Virtual Hard Disk.
12. Click Next.
13. Take a moment to verify the information that is displayed on
the confirmation screen and click Create.
14. After you have created the virtual disk, click Close.
15. Windows will automatically launch the New Volume wizards. Click Next to
bypass the wizard’s Welcome screen.
16. When prompted, select your storage pool and the virtual disk that you
have created.
17. Click Next.
18. Specify the size of the volume and click Next.
19. Assign a drive letter to the volume and click Next.
20. Choose the file system that you want to use on the volume and click Next.
21. Verify the information displayed on the confirmation screen
and click Create.
22. When the volume has been created, click Close (Figure 2.42).
61
Understanding Hyper-V in Windows Server 2012
Figure 2.42
Verify that the virtual disk has been created successfully.
Building an iSCSI target
As previously mentioned, Cluster Shared Volumes are normally accessed either
through iSCSI or through Fibre Channel. For the sake of demonstration, this
section will show you how to create an iSCSI target for the recently created
storage volume.
Microsoft supported configuring Windows Server 2008 R2 as an iSCSI target,
but doing so required you to download an additional component. In Windows
Server 2012, the iSCSI target software is built into the operating system,
so there is nothing extra to download.
Starting the iSCSI Initiator
Before you begin configuring the iSCSI target, it is helpful to start the iSCSI
Initiator on each of the cluster nodes. The reason for doing this now is that
each of the cluster nodes will be assigned an iSCSI Qualified Name (IQN). You
will need to provide each node’s IQN when you configure the iSCSI target. To
start each node’s iSCSI Initiator, complete these steps:
1. Open the Server Manager.
2. Choose the iSCSI Initiator command from the Tools menu
3. You should see a message indicating that the Microsoft iSCSI Service is not
running. Click Yes to start the service.
4. When the iSCSI Initiator launches, go to the properties sheet’s
Configuration tab and note the Initiator Name (Figure 2.43).
5. Repeat these steps for each cluster node.
62
Understanding Hyper-V in Windows Server 2012
Figure 2.43
Note the IQN for each cluster node.
Installing the iSCSI target software
Although Windows Server 2012 includes the iSCSI target software, it is not
installed by default. To deploy the iSCSI target software onto the server that
will host your Cluster Shared Volume, follow these steps:
1. Open the Server Manager.
2. Choose the Add Roles and Features command from the Manage menu.
3. When the Add Roles and Features Wizard launches, click Next to bypass
the wizard’s Welcome screen.
4. On the Select Installation Type screen, choose the Role‑Based
or Feature‑Based Installation option (Figure 2.44).
63
Understanding Hyper-V in Windows Server 2012
Figure 2.44
Choose the Role-Based or Feature-Based Installation option.
5. Click Next.
6. Verify that the server that will host the Cluster Shared Volume is selected
(Figure 2.45).
Figure 2.45
Make sure that the server that will host the iSCSI target is selected.
64
Understanding Hyper-V in Windows Server 2012
7. Click Next.
8. On the Select Server Roles screen, verify that the File and Storage
Services role is installed. This role should be installed by default.
9. Expand the File and Storage Services container.
10. Expand the File and iSCSI Services container (Figure 2.46).
11. Select the iSCSI Target Server option and the iSCSI Target Storage
Provider option. If you are prompted to add additional features to support
those services, click the Add Features button.
Figure 2.46
Select the iSCSI Target Software and the iSCSI Target Storage Provider components.
12. Click Next.
13. Click Next on the Select Features screen (it is not necessary to deploy
any additional features at this time).
14. When you reach the confirmation screen, click Install (Figure 2.47).
65
Understanding Hyper-V in Windows Server 2012
Figure 2.47
Click Install to install the iSCSI Target software.
15. When the installation completes, click Close.
Configuring the iSCSI target
Now that you have installed the iSCSI target software, you need to configure it.
This means creating an iSCSI virtual disk (within the virtual disk that was already
created in Windows Storage Spaces). You will also need to provide the iSCSI
target with an authentication method as well as the IQNs of the cluster nodes.
To configure the iSCSI target software, follow these steps:
1. Open the Server Manager if it is not already open.
2. Click on the File and Storage Services option, found in the console tree.
3. Click on iSCSI.
4. Click the To Create an iSCSI Virtual Disk, Start the New iSCSI Virtual Disk
Wizard link (Figure 2.48).
Figure 2.48
Click the To Create an iSCSI Virtual Disk, Start the New iSCSI Virtual Disk Wizard link.
66
Understanding Hyper-V in Windows Server 2012
5. When the New iSCSI Virtual Disk Wizard begins, select your storage pool
and the volume that you just created (Figure 2.49).
Figure 2.49
Select the volume that you just created.
6. Click Next.
7. Specify a name and an optional description for the iSCSI virtual disk
and click Next.
8. Specify a size for the iSCSI virtual disk and click Next.
9. Choose the New iSCSI Target option and click Next.
10. Enter a name and an optional description for the iSCSI target and click
Next.
11. Add the names of the iSCSI initiators that will access the target. Populate
the dialog box with the IQN names from the iSCSI initiators on all of your
cluster nodes (Figure 2.50).
67
Understanding Hyper-V in Windows Server 2012
Figure 2.50
You must provide the IQNs of your iSCSI initiators.
12. Once all of the cluster nodes have been added to the list, click Next.
13. Although not technically required, authentication is important for iSCSI
connectivity. Otherwise someone could easily spoof an IQN and gain
access to your iSCSI target. The wizard gives you a choice of enabling
CHAP or reverse CHAP authentication. As a best practice, you should
enable CHAP and provide a strong name and password (Figure 2.51).
Please note that your password must be at least 12 characters in length.
68
Understanding Hyper-V in Windows Server 2012
Figure 2.51
It is a good idea to use CHAP authentication for your iSCSI target.
14. Click Next.
15. Verify the information shown in the confirmation screen, and click Create
(Figure 2.52).
Figure 2.52
Take a moment to identify the iSCSI target configuration information.
16. When the process completes, click Close.
69
Understanding Hyper-V in Windows Server 2012
Attaching the cluster nodes to the iSCSI storage
Now that you have created the iSCSI target and authorized the individual
cluster nodes to use the target, it is time to attach the cluster nodes to the
iSCSI target. You can do so by performing the following procedure on each
cluster node:
1. Open the Server Manager.
2. Choose the iSCSI Initiator from the Tools menu.
3. When the iSCSI Initiator opens, go to the Targets tab.
4. Enter the IP address of the server that is hosting the iSCSI target in
the Target field.
5. Click the Quick Connect button.
6. You should see your iSCSI target listed as inactive (Figure 2.53). Select
the iSCSI target and click Done.
Figure 2.53
Your iSCSI target should be listed as inactive.
70
Understanding Hyper-V in Windows Server 2012
7. You should now be returned to the main initiator screen with the Targets
tab selected (Figure 2.54).
Figure 2.54
Your target should be listed on the Targets tab.
8. Select the target, which should be listed as inactive, and click
the Connect button.
9. Verify that the target name is correct and that the Add this Connection to
the List of Favorite Targets option is selected (Figure 2.55).
71
Understanding Hyper-V in Windows Server 2012
Figure 2.55
You must add the target to the list of favorite targets and enable multi-path.
10. Select the Enable Multi-Path check box. This is a critical step because
you won’t be able to create a Cluster Shared Volume unless this option
is selected.
11. Click the Advanced button.
12. When the Advanced Settings dialog box launches, select the Enable
CHAP Log On check box (Figure 2.56).
Figure 2.56
You must choose the Enable CHAP Log On option and enter your CHAP credentials.
72
Understanding Hyper-V in Windows Server 2012
13. Enter the name that you specified earlier. You should enter the CHAP
password into the Target Secret field.
14. Click OK.
15. Click OK.
16. When you are returned to the Targets tab, the iSCSI Target should be
listed as Connected.
17. Click OK to close the iSCSI Initiator Properties sheet.
18. Repeat this procedure on the remaining cluster nodes so that each cluster
node has iSCSI connectivity to the target.
Making storage available to the cluster
Now that you have connected each cluster node to the iSCSI target, you must
prepare the iSCSI storage for use by the cluster. This means creating the volume
and configuring the cluster to recognize the shared storage. To do so, follow
these steps:
1. Enter the DISKMGMT.MSC command to open the Disk Management
Console.
2. When the Disk Management Console opens, locate the iSCSI volume.
3. Right-click on the disk associated with the iSCSI target and choose
the Online command from the right-click menu (Figure 2.57).
Figure 2.57
You must bring the Cluster Shared Volume online.
4. Right-click on the disk associated with the iSCSI target and choose
the Initialize Disk command from the right-click menu.
5. When prompted, select the type of partition that you wish to use with
the disk (Figure 2.58) and click OK.
73
Understanding Hyper-V in Windows Server 2012
Figure 2.58
Select the type of partition that you wish to use for your Cluster Shared Volume and click OK.
6. Right-click on the unallocated space and create a volume. Do not assign
a drive letter to the volume.
7. Close the Disk Management Console.
8. Open the Server Manager.
9. Choose the Failover Cluster Manager option from the Tools menu.
10. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster name> | Storage | Disks
(Figure 2.59).
Figure 2.59
Navigate through the Failover Cluster Manager to Failover Cluster Manager | <your cluster
name> | Storage | Disks.
11. Click the Add Disk link, found in the Actions pane.
12. The Failover Cluster Manager should automatically recognize your iSCSI
Target as a disk that can be added to the cluster (Figure 2.60). Verify that
the disk is selected and click OK.
74
Understanding Hyper-V in Windows Server 2012
Figure 2.60
Select the Custer Shared Volume and click OK.
13. The Failover Cluster Manager should list the disk as being available to
the cluster and show the disk status as Online (Figure 2.61). It is worth
noting that it can occasionally take a minute or two for the disk status to
be updated.
Figure 2.61
The Cluster Shared Volume should be listed within the Failover Cluster Manager.
14. With the cluster disk selected, click Add to Cluster Shared Volumes.
Installing the Hyper-V role
The next step in the process is to install the Hyper-V role. You must install this
role into each of the cluster nodes. You can complete this process by following
these steps:
1. Open the Server Manager.
2. Choose the Add Roles and Features command from the Manage menu.
3. When the Add Roles and Features wizard launches, click Next to bypass
the wizard’s Welcome screen.
75
Understanding Hyper-V in Windows Server 2012
4. Make sure that the Role-Based or Feature-Based Installation option is
selected and click Next.
5. Select the server on which you want to deploy the Hyper-V role and click
Next.
6. Select the Hyper-V option from the list of roles.
7. If you are prompted to add additional features, click the Add Features
button.
8. Click Next.
9. Click Next.
10. Click Next.
11. Select the network adapters that you want to connect to the virtual switch
(Figure 2.62). You can select multiple network adapters, but as a best
practice you should reserve a network adapter for management traffic
and you should reserve an adapter for cluster communications (such as
cluster heartbeats and live migration traffic).
Figure 2.62
Select the network adapters to be used by Hyper-V.
12. Click Next.
13. Select the checkbox for Allow this Server to Send and Receive Live
Migrations of Virtual Machines (Figure 2.63).
76
Understanding Hyper-V in Windows Server 2012
Figure 2.63
Your cluster nodes must be able to live migrate virtual machines.
14. Select the authentication protocol to be used by live migration traffic.
If the cluster nodes reside in the same Active Directory domain as one
another then you should use the Kerberos protocol. Kerberos is more
secure than CredSSP and the configuration process is easier.
15. Click Next.
16. Click Next to accept the default store location.
17. Take a moment to verify the information that is displayed on
the Confirmation screen and then click Install.
18. When the installation process completes, click Close and then reboot
the server.
19. Repeat these steps for each node in the cluster.
Making Hyper-V fault tolerant
Now that you have installed the Hyper-V role, the next step in the process is
to make Hyper-V and your virtual machines fault tolerant. The simple act of
creating a virtual machine does not make the virtual machine fault tolerant.
You must create the virtual machine in the correct location and you will have to
designate the virtual machine as being fault tolerant.
When you create a new virtual machine, the New Virtual Machine Wizard asks
if you want to store the virtual machine in a different location (see Chapter 6
for details). If you want the virtual machine to be fault tolerant, you must store
the virtual machine on the Cluster Shared Volume.
77
Understanding Hyper-V in Windows Server 2012
As you may recall, you created a volume on the iSCSI target, but did not
assign a drive letter to it. You can access the Cluster Shared Volume at C:\
ClusterStorage\<your volume name>. Anything that you save to this path will
reside on the Cluster Shared Volume (the iSCSI target) rather than on the local
C: drive.
Simply storing the virtual machines on the Cluster Shared Volume is not
enough (Figure 2.64). As you can see in the figure, three virtual machines have
been created, and each of these virtual machines resides on the Cluster Shared
Volume. If you look at the lower middle pane in the next figure, however, you
will notice that the Hyper-V Manager indicates that the virtual machine is not
clustered (Figure 2.65).
Figure 2.64
Virtual machines must be stored on the Cluster Shared Volume.
78
Understanding Hyper-V in Windows Server 2012
Figure 2.65
Even with the virtual machines residing on the Cluster Shared Volume, the virtual machines
are not considered to be fault tolerant.
To make the virtual machine fault tolerant you must designate it as such
through the Failover Cluster Manager. To do so, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager from the list of tools.
3. When the Failover Cluster Manager opens, navigate through the
console tree to Failover Cluster Manager | <your cluster name> | Roles
(Figure 2.66).
Figure 2.66
Navigate through the Failover Cluster Manager to Failover Cluster Manager | <your cluster
name> | Roles.
79
Understanding Hyper-V in Windows Server 2012
4. Click the Configure Role link, found in the Actions pane.
5. Windows will now launch the High Availability Wizard. Click Next to
bypass the wizard’s Welcome screen.
6. The next screen lists a variety of server roles. Select the Virtual Machine
role from the list and click Next (Figure 2.67).
Figure 2.67
Select the Virtual Machines option.
7. Select the virtual machines that you wish to make fault tolerant and click
Next (Figure 2.68).
80
Understanding Hyper-V in Windows Server 2012
Figure 2.68
Select the virtual machines that you wish to make fault tolerant.
8. Verify the information displayed on the confirmation screen and click
Next.
9. When the process completes you should see a message confirming that
high availability was successfully configured (Figure 2.69). Click the View
Report button to examine the report. Click Finish.
Figure 2.69
Click the View Report button to see a report of the operation.
81
Understanding Hyper-V in Windows Server 2012
After the virtual machines become fault tolerant, you should see them listed
in the Failover Cluster Manager’s Roles container (Figure 2.70). Likewise,
the Hyper-V Manager should list the virtual machine as being clustered
(Figure 2.71).
Figure 2.70
The Failover Cluster Manager now displays the virtual machines.
82
Understanding Hyper-V in Windows Server 2012
Figure 2.71
The Hyper-V Manager lists the virtual machines as being clustered.
Using SMB storage
This chapter has focused primarily on the use of local, direct attached storage
and on connecting to a Cluster Shared Volume through iSCSI. However, those
are not your only options. Hyper-V is also able to store virtual machines on an
SMB file share in both clustered and non-clustered environments.
The use of SMB storage is generally only practical for smaller organizations
because bandwidth limitations impact the number of virtual machines that can
reside on a file share. The use of SMB file share storage for virtual machines is
most useful when a file server has been configured to be highly available.
Finally, storing virtual machines on SMB file shares is only an option if
the servers involved are using SMB version 2.2 or higher. Earlier versions of
SMB are not supported.
83
Understanding Hyper-V in Windows Server 2012
Chapter 3
Migrations
In the previous chapter, you spent a lot of time building
failover clusters and making virtual machines fault tolerant.
However, building the cluster is really just the beginning.
It is equally important to know how to verify that
your failover cluster is working properly. As a Hyper-V
administrator, you will also need to know how to move
virtual machines around both within and outside of
the cluster. This chapter discusses all of these tasks.
84
Understanding Hyper-V in Windows Server 2012
Testing failover clustering
One of the nice things about building a failover cluster is that you have
the assurance that if any of your cluster nodes were to fail, the virtual machines
that had been running on the failed node will automatically fail over to a node
that is still functioning. Of course this raises the question of how you can test
virtual machine failover. Simply shutting down a cluster node is an inadequate
test because a graceful shutdown is not as abrupt as an unexpected node
failure. At the same time, however, you don’t want to be yanking the power
cord out of a cluster node to see what would happen in the event of
a real failure.
The ability to test virtual machine failover was something that was sorely
lacking from Hyper-V 2.0. Thankfully, Microsoft has included a testing feature
in Hyper-V 3.0.
Live migrating a VM within the cluster
Although a failover cluster is designed to automatically move a virtual machine
to a functioning cluster node in the event of a failure, you may occasionally
want to move a virtual machine to another cluster node even if no failure has
occurred. For example, if you are planning to take a cluster node down for
maintenance then you would probably want to move the virtual machines to
another node before doing so. Likewise, if you determine that a single cluster
node is handling a disproportionate amount of the cluster’s total workload, you
might decide to move some of the virtual machines to another node.
Performing a live migration within a cluster is simple. To do so, complete
these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your Cluster> | Roles.
4. Right-click on the virtual machine that you want to live migrate and select
the Move | Live Migration | Select Node commands from the right-click
menus (Figure 3.1). As an alternative, you can allow Hyper-V to select
the destination cluster node by choosing the Best Possible Node option.
85
Understanding Hyper-V in Windows Server 2012
Figure 3.1
You can select the destination node manually, or you can let Hyper-V pick the best
node automatically.
5. Choose the cluster node to which you want to live migrate the virtual
machine (Figure 3.2).
Figure 3.2
Select the cluster node to which you want to live migrate the virtual machine.
6. Click OK.
7. You can monitor the live migration process through the Failover Cluster
Manager (Figure 3.3).
86
Understanding Hyper-V in Windows Server 2012
Figure 3.3
The Failover Cluster Manager displays the progress of the live migration.
8. When the live migration completes, the Failover Cluster Manager should
report the virtual machine as running on the cluster node that you have
selected (as shown in the Owner Node column) (Figure 3.4).
Figure 3.4
The Owner Node column confirms that the virtual machine has been moved to a different
cluster node.
Configuring a server to send and receive
live migrations
Hyper-V doesn’t limit you to performing virtual machine migrations within
the confines of a cluster. You can also perform live migrations between
standalone Hyper-V hosts or even between Hyper-V clusters, but the hosts
involved must be configured to allow live migrations.
If you followed the instructions from the previous chapter, your cluster should
be capable of live migrating virtual machines within a cluster. However, if you
have a standalone Hyper-V host that was not initially configured to allow live
migrations, that host will need to be reconfigured prior to using it in any live
migration scenario. To configure a Hyper-V Host to allow live migrations, follow
these steps:
1. Open the Hyper-V Manager.
2. Right-click on your host server and choose the Hyper-V Settings
command from the right-click menu (Figure 3.5).
87
Understanding Hyper-V in Windows Server 2012
Figure 3.5
Right-click on the listing for the host server and select the Hyper-V Settings command from
the right-click menu.
3. When the Hyper-V Settings dialog box launches, select the Live
Migrations option (Figure 3.6).
Figure 3.6
Select the Live Migrations tab.
88
Understanding Hyper-V in Windows Server 2012
4. Select the Enable Incoming and Outgoing Live Migrations check box
(Figure 3.7).
Figure 3.7
You must manually enable incoming and outgoing live migrations.
5. Specify the authentication protocol to use. Kerberos is the preferred
authentication protocol because it is more secure and the configuration
process is easier, but it only works within a common Active
Directory forest.
6. Specify the maximum number of simultaneous live migrations to allow.
7. Specify the IP addresses for the NICs with which the server is authorized
to live migrate virtual machines. You can select the Use Any Available
Network for Live Migration option, but this is less secure than the Use
These IP Addresses for Live Migration option.
8. Click OK to complete the process.
Dealing with CPU mismatch
If you plan to live migrate virtual machines between Hyper-V hosts, it is best
to use identical hardware on all of your cluster nodes if possible. Of course
acquiring identical hardware is not always possible. The next best thing
is to use servers with identical CPUs. If you attempt to live migrate virtual
machines between servers with dissimilar CPUs you will receive an error
message indicating that the virtual machine is using processor-specific features
and cannot be migrated (Figure 3.8).
89
Understanding Hyper-V in Windows Server 2012
Figure 3.8
You will receive an error message if the CPUs on the source and destination hosts are
too dissimilar.
The solution to this problem is to enable CPU compatibility. You can accomplish
this by following these steps:
1. Open the Hyper-V Manager.
2. Shut down the virtual machine.
3. Right-click on the virtual machine and choose the Settings command from
the right-click menu.
4. Expand the Processor container in the resulting dialog box.
5. Select the Compatibility container.
6. Select the checkbox for Migrate to a Physical Computer with a Different
Processor Version (Figure 3.9).
7. Click OK.
8. Restart the virtual machine.
9. Attempt the live migration.
90
Understanding Hyper-V in Windows Server 2012
Figure 3.9
You can overcome some live migration issues by enabling the processor compatibility feature.
It is worth noting that enabling the CPU compatibility feature does not allow
you to move virtual machines between hosts with different CPU architectures
(e.g., moving from a host with an Intel processor to a host with an AMD
processor). Furthermore, enabling CPU compatibility might impact the virtual
machine’s performance because the feature works by disabling the virtual
machine’s access to some of the more advanced CPU features such as
Misaligned SSE or POPCNT.
Live migrations beyond the cluster
One of the really interesting things that Microsoft has done in Hyper-V 3.0 is
to make it possible to live migrate virtual machines from one host to another
regardless of whether or not the host servers are clustered. In Hyper-V 3.0 you
can perform the following types of migrations:
• Cluster node → cluster node
• Cluster node → standalone host
• Standalone host → cluster node
• Standalone host → standalone host
For the most part, Microsoft offers these types of migrations as a convenience
feature. For example, suppose that you have a non-clustered Hyper-V
server that is running your production virtual machines. Now suppose
that you purchase some new servers and build a Hyper-V cluster. In that
type of situation it is possible to use live migration to move running virtual
machines from the standalone server onto a cluster node. After doing so,
you can configure the Failover Cluster Manager to make the virtual machines
fault tolerant.
91
Understanding Hyper-V in Windows Server 2012
Although it is easy to think of live migrations as a clustering feature, Hyper-V
makes it possible to live migrate virtual machines even if the host servers that
are involved in the migration process are not clustered.
Live migrating a VM to a server outside of the cluster
The first technique involves moving a clustered virtual machine to a non
clustered Hyper-V host. This procedure requires you to remove the virtual
machine’s fault tolerance as a part of the migration process.
Before you begin the migration process, choose the type of move that you
want to perform. Hyper-V gives you three different options including:
• Move the Virtual Machine’s Data to a Single Location – This option places
all of the virtual machine components into a single location.
• Move the Virtual Machine’s Data by Selecting Where to Move Each Item –
This option gives you the most flexibility because it allows you to control
where each virtual machine component will be placed. This is usually
the option that you will use when performing cluster-to-standalone
host migrations.
• Move Only the Virtual Machine – This option moves the virtual machine
itself to a new host, but leaves the Virtual Hard Disk in its original location
on the Cluster Shared Volume.
The steps below describe the procedure for moving a clustered virtual machine
to a Hyper-V host that exists outside of the cluster. This procedure assumes
that all of the host servers exist within a common domain and that you will be
specifying where to move the various virtual machine components. To perform
the virtual machine migration, follow these steps:
1. Open the Server Manager.
2. Select the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster> | Roles.
4. Select the virtual machine that you want to migrate away from the cluster.
5. Right-click on the virtual machine and select the Remove command from
the right-click menu (Figure 3.10).
92
Understanding Hyper-V in Windows Server 2012
Figure 3.10
Right-click on the virtual machine and select the Remove command from
the right‑click menu.
6. When you see the prompt asking if you want to remove the virtual
machine, click Yes (Figure 3.11).
Figure 3.11
Confirm that you want to remove the virtual machine from the cluster.
7. Close the Failover Cluster Manager.
8. Open the Hyper-V Manager.
9. Verify that the virtual machine is still running, and that it is not clustered
(Figure 3.12).
93
Understanding Hyper-V in Windows Server 2012
Figure 3.12
Make sure that the VM is still running and that it is no longer clustered.
10. Right-click on the virtual machine and choose the Move command from
the right-click menu.
11. When the Move Wizard starts, click Next to bypass the wizard’s
Welcome screen.
12. Choose the Move the Virtual Machine option and click Next (Figure 3.13).
94
Understanding Hyper-V in Windows Server 2012
Figure 3.13
Choose the option to move the virtual machine.
13. When prompted, enter the name of the destination host (Figure 3.14).
Figure 3.14
Specify the name of the destination host.
95
Understanding Hyper-V in Windows Server 2012
14. Click Next.
15. Choose the option to Move the Virtual Machine’s Data by selecting
Where to Move the Items (Figure 3.15).
Figure 3.15
Choose the option to move the virtual machine by selecting where to move each item.
16. Click Next.
17. Choose the option for moving the virtual machine’s components. It is
usually acceptable to choose the option to Move the Virtual Machine’s
Data Automatically (Figure 3.16). This option places the virtual machine
components in the same locations on the destination host as the locations
in which they resided on the source host.
96
Understanding Hyper-V in Windows Server 2012
Figure 3.16
It is usually acceptable to move the virtual machine’s data automatically.
18. Click Next.
19. Verify the information presented on the Summary screen.
20. Click Finish.
Live migrating an external VM into the cluster
If you have been using Hyper-V for a while, but are new to clustering, you
might encounter a situation in which you need to bring some production
virtual machines into a newly built cluster. Although you can use the Export /
Import method, it is usually easier to live migrate the virtual machines
from the standalone Hyper-V server into the cluster. This process involves
completing two main tasks: 1) migrate the virtual machine and 2) make
the virtual machine fault tolerant once it is running on a cluster node.
The procedure listed below assumes that the standalone Hyper-V host and all
of the cluster nodes belong to the same Active Directory domain and that
live migrations are enabled on all hosts. The procedure also assumes that
the cluster makes use of a Cluster Shared Volume. However, the procedure can
be easily adapted for environments without shared storage or for organizations
in which hosts reside in multiple domains. To perform the live migration,
complete the following steps:
1. Open the Hyper-V Manager on the standalone server that contains
the virtual machine that is to be migrated to the cluster.
2. Right-click on the virtual machine and choose the Move command from
the right-click menu.
97
Understanding Hyper-V in Windows Server 2012
3. When the Move Wizard opens, click Next to bypass the Welcome screen.
4. On the following screen, select the Move the Virtual Machine option and
click Next (Figure 3.17).
Figure 3.17
Select the Move the Virtual Machine option.
5. When prompted, enter the name of one of the cluster nodes (Figure 3.18).
Figure 3.18
Enter the name of the destination host.
98
Understanding Hyper-V in Windows Server 2012
6. Click Next.
7. Choose the Move the Virtual Machine’s Data to a Single Location option
(Figure 3.19).
Figure 3.19
Move the virtual machine to a single location.
8. Click Next.
9. Switch to the specified cluster node, open Windows Explorer and navigate
to C:\ClusterStorage\<volume name> (Figure 3.20).
99
Understanding Hyper-V in Windows Server 2012
Figure 3.20
Open Windows Explorer and navigate to your Cluster Shared Volume.
10. Create a folder matching the name of the virtual machine that is
to be migrated.
11. Switch back to the standalone host server where the virtual machine
currently resides.
12. Enter C:\ClusterStorage\<volume name>\<virtual machine name> as
the destination location folder (Figure 3.21).
Figure 3.21
Enter the path in which the virtual machine will be stored.
100
Understanding Hyper-V in Windows Server 2012
13. Verify that the destination folder has sufficient free disk space. The amount
of disk space required is listed in the Source Location portion of
the wizard’s current screen.
14. Click Next.
15. If the cluster node does not contain a virtual switch with a name matching
the virtual switch that is currently in use, you will be asked to specify
a virtual switch (Figure 3.22). Make your selection and click Next.
Figure 3.22
Specify the virtual switch that the virtual machine will use after the migration.
16. Verify the summary information and click Finish.
17. When the migration process completes, go to the destination cluster node
and verify that the virtual machine is running.
18. Switch to the destination cluster node and verify that the virtual machine is
present and running (Figure 3.23).
101
Understanding Hyper-V in Windows Server 2012
Figure 3.23
Verify that the virtual machine is running in its new location.
19. Open the Server Manager.
20. Choose the Failover Cluster Manager option from the Tools menu.
21. Navigate through the Failover Cluster Manager to Failover Cluster
Manager | <your cluster> | Roles.
22. Click on the Configure Roles link, found in the Actions pane.
23. When the High Availability Wizard launches, click Next to bypass
the Welcome screen.
24. Select the Virtual Machine option and click Next (Figure 3.24).
102
Understanding Hyper-V in Windows Server 2012
Figure 3.24
Select the Virtual Machine option from the list of high availability roles.
25. Select the recently migrated virtual machine from the list of virtual
machines and click Next (Figure 3.25).
Figure 3.25
Select the virtual machine that you want to make highly available.
103
Understanding Hyper-V in Windows Server 2012
26. Verify that the correct virtual machine is listed on the summary screen
and click Next.
27. Verify that the virtual machine was made highly available (Figure 3.26).
28. Click Finish.
Figure 3.26
You can use the report to verify the success of the operation.
Cluster-to-cluster live migrations
Just as you can live migrate virtual machines into and out of a cluster, you can
use a similar technique to live migrate a virtual machine between clusters.
When you do this, there will be a period of time during which the virtual
machine is not fault tolerant, but the virtual machine will remain online
throughout the migration process.
The technique described in this section assumes that all of the cluster nodes
exist within a common domain. It is also assumed that both clusters use shared
storage, although you can easily adapt the technique to a cluster that does not
use shared storage. To perform a cluster-to-cluster live migration, follow
these steps:
1. Open the Server Manager.
2. Select the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, navigate through the console
tree to Failover Cluster Manager | <your cluster> | Roles.
4. Select the virtual machine that you want to migrate to another cluster
(Figure 3.27).
104
Understanding Hyper-V in Windows Server 2012
Figure 3.27
Select the virtual machine that you want to move to another cluster.
5. Right-click on the virtual machine and select the Remove command from
the right-click menu.
6. When you see the prompt asking if you want to remove the virtual
machine, click Yes (Figure 3.28).
Figure 3.28
Click Yes to remove the virtual machine from the cluster.
7. Close the Failover Cluster Manager.
8. Open the Hyper-V Manager.
9. Verify that the virtual machine is still running, and that it is not clustered
(Figure 3.29).
Figure 3.29
Make sure that the VM is still running and that it has been removed from the cluster.
105
Understanding Hyper-V in Windows Server 2012
10. Right-click on the virtual machine and choose the Move command from
the right-click menu.
11. When the Move Wizard launches, click Next to bypass the wizard’s
Welcome screen.
12. Choose the option to Move the Virtual Machine (Figure 3.30)
and click Next.
Figure 3.30
Choose the Move the Virtual Machine option.
13. When prompted, enter the name of the destination host.
14. Click Next.
15. Choose the option to Move the Virtual Machine’s Data to a Single
Location (Figure 3.31).
106
Understanding Hyper-V in Windows Server 2012
Figure 3.31
Choose the option to move the virtual machine to a single location.
16. Click Next.
17. Switch to a node on the destination folder.
18. Open Windows Explorer and navigate to C:\ClusterStorage\
<volume name>
19. Create a folder bearing the name of the virtual machine that is to
be migrated.
20. Switch back to the cluster node where the virtual machine is
currently running.
21. Enter the path where the virtual machine will reside. The path should be
C:\ClusterStorage\<volume name>\<virtual machine name> (Figure 3.32).
107
Understanding Hyper-V in Windows Server 2012
Figure 3.32
Enter the path where the virtual machine should be stored on the destination cluster.
22. Verify that the destination folder has sufficient free disk space. The amount
of disk space required is listed in the Source Location portion of
the wizard’s current screen.
23. Click Next.
24. If the cluster node does not contain a virtual switch with a name matching
the virtual switch that is currently in use, you will be asked to specify
a virtual switch. Make your selection and click Next.
25. Verify the summary information and click Finish.
26. When the migration process completes, go to the destination cluster node
and verify that the virtual machine is running.
27. Switch to the destination cluster node and verify that the virtual machine is
present and running.
28. Open the Server Manager.
29. Choose the Failover Cluster Manager option from the Tools menu.
30. Navigate through the Failover Cluster Manager to Failover Cluster
Manager | <your cluster> | Roles.
31. Click on the Configure Roles link, found in the Actions pane.
32. When the High Availability Wizard launches, click Next to bypass
the Welcome screen.
33. Select the Virtual Machine option and click Next (Figure 3.33).
108
Understanding Hyper-V in Windows Server 2012
Figure 3.33
Select the Virtual Machine option from the list of roles that can be configured for
high availability.
34. Select the recently migrated virtual machine from the list of virtual
machines and click Next.
35. Verify that the correct virtual machine is listed on the summary screen
and click Next.
36. Verify that the virtual machine was made highly available.
37. Click Finish.
38. The virtual machine should now be displayed as a clustered resource
within the Failover Cluster Manager (Figure 3.34).
Figure 3.34
The virtual machine should be displayed within the Failover Cluster Manager.
109
Understanding Hyper-V in Windows Server 2012
Storage live migrations
Just as it is sometimes necessary to live migrate a virtual machine from one
Hyper-V host to another, it is also sometimes necessary to perform a storage
live migration. A storage live migration moves the virtual machine components
(Virtual Hard Disks, snapshots, etc.) from one storage location to another
without requiring the virtual machine itself to be moved to another host. This
is helpful when the volume containing virtual machine components is running
low on space or when the volume needs to be taken offline for maintenance.
As is the case with live migrations, storage live migrations can be performed
against a running virtual machine without causing a service interruption.
Storage migration within a cluster
The technique you use to perform a storage live migration varies depending
upon whether or not the virtual machine is fault tolerant. This section starts by
examining a technique for clustered environments. In this example, a virtual
machine is running on a Cluster Shared Volume and you will move the virtual
machine to an SMB volume. To perform this type of storage live migration,
complete the following steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager option from the Tools menu.
3. Navigate through the Failover Cluster Manager console to Failover Cluster
Manager | <your cluster> | Roles.
4. Right-click on the virtual machine on which you wish to perform a storage
migration and choose the Move | Virtual Machine Storage commands
from the right-click menus (Figure 3.35).
Figure 3.35
Right-click on a virtual machine and choose the Move | Virtual Machine Storage commands
from the right-click menu.
110
Understanding Hyper-V in Windows Server 2012
5. The Cluster Storage section is displayed in the lower left portion of
the Move Virtual Machine Storage window. If you have not previously
performed a storage live migration at the cluster level, this window
typically displays an error message stating that the network path was not
found. Right-click on this error and choose the Add Share command from
the right-click menu (Figure 3.36).
Figure 3.36
Right-click in the Cluster Storage section and choose the Add Share option.
6. When the Add a Network Share dialog box launches, enter the UNC share
name (\\servername\sharename) for the destination storage and click OK
(Figure 3.37).
Figure 3.37
Enter the path to the network share in UNC format.
7. Confirm that the Move Virtual Machine Storage dialog box lists
the specified network share in the Shares section (Figure 3.38).
111
Understanding Hyper-V in Windows Server 2012
Figure 3.38
Verify that the UNC path is displayed in the Shares section.
8. Drag the virtual machine from the top section of the dialog box to
the listing for the share that you have specified. The dialog box should
update to display the items that will be moved (Figure 3.39).
Figure 3.39
You should see the virtual machine components that are about to be migrated.
112
Understanding Hyper-V in Windows Server 2012
9. Click the Start button.
10. The Failover Cluster Manager should confirm that the storage migration
has begun (Figure 3.40). Although the virtual machine displayed in this
screen capture is powered off, the move could just as easily have been
performed while the virtual machine was running.
Figure 3.40
The Failover Cluster Manager should confirm that virtual machine migration has begun.
Storage migrations outside of a cluster
When it comes to performing storage migrations for non-clustered virtual
machines, you have three options: moving the entire virtual machine to a single
location, moving the virtual machine’s data to different locations or moving
only the Virtual Hard Disks. The sections below provide walkthroughs for all
three types of storage migrations.
Moving all of the virtual machine’s data to a single location
The first option is to move all of the virtual machine data to a single location.
This is the easiest of the storage live migration options and is likely to be
the option that you will use most often. To complete this type of storage live
migration, follow these steps:
1. Open the Hyper-V Manager.
2. Right-click on the virtual machine for which you wish to perform a storage
migration, and select the Move command from the right-click menu
(Figure 3.41).
Figure 3.41
Right-click on a VM and choose the Move command from the right-click menu.
113
Understanding Hyper-V in Windows Server 2012
3. When the Move wizard launches, click Next to bypass the wizard’s
Welcome screen.
4. Choose the option to move the virtual machine’s storage, and click Next
(Figure 3.42).
Figure 3.42
Choose the option to move the virtual machine’s storage.
5. Choose the option to Move All of the Virtual Machine’s Data to a Single
Location (Figure 3.43).
114
Understanding Hyper-V in Windows Server 2012
Figure 3.43
Choose the option to move all of the virtual machine’s data to a single location.
6. Click Next.
7. Specify the folder to which you want to move the virtual machine
(Figure 3.44). Pay attention to the Current Location section within
the wizard’s current screen. This section tells you how much physical disk
space the virtual machine is currently consuming. You must verify that
there is sufficient disk space in the new location.
115
Understanding Hyper-V in Windows Server 2012
Figure 3.44
Specify the path to which you want to move the virtual machine.
8. Click Next.
9. Verify the information shown on the Summary screen.
10. Click Finish.
Moving the virtual machine’s data to different locations
The second option for performing storage live migrations involves moving
virtual machine data to different locations. This option is useful for storage
migrations that require a bit more granular control. For instance, you can
use this option to place Virtual Hard Disk files in one storage location and
snapshot files in another. To perform this type of storage live migration, follow
these steps:
1. Open the Hyper-V Manager.
2. Right-click on the virtual machine for which you wish to perform a storage
migration and select the New command from the right-click menu.
3. When the Move wizard launches, click Next to bypass the wizard’s
Welcome screen.
4. Choose the option to move the virtual machine’s storage, and click Next.
5. Choose the option to Move the Virtual Machine’s Data to a Different
Locations (Figure 3.45).
116
Understanding Hyper-V in Windows Server 2012
Figure 3.45
Choose the option to move the virtual machine’s data to different locations.
6. Click Next.
7. Choose the virtual machine components that you want to move
(Figure 3.46) and click Next.
Figure 3.46
Select the virtual machine components that you want to move.
117
Understanding Hyper-V in Windows Server 2012
8. If you have chosen to move the Virtual Hard Disk, you will be prompted to
enter a new location for it (Figure 3.47). Enter the path to the Virtual Hard
Disk’s new location and click Next.
Figure 3.47
If prompted, enter a path in which to store the Virtual Hard Disk.
9. If you have chosen to move the virtual machine’s configuration, you will be
prompted to enter a path to the new location (Figure 3.48). Enter a path to
use for the virtual machine’s configuration and click Next.
118
Understanding Hyper-V in Windows Server 2012
Figure 3.48
Enter a path in which to store the virtual machine’s configuration.
10. If you have chosen to move the virtual machine snapshots, you will
be prompted to specify a path to the new location. Enter a path
and click Next.
11. If you have chosen to move the Smart Paging files, you will be prompted
to enter a new location for them (Figure 3.49). Enter a path for the smart
paging files and click Next.
119
Understanding Hyper-V in Windows Server 2012
Figure 3.49
Enter the path in which to store the smart paging file.
12. Verify the information on the summary screen and click Finish.
Moving only the Virtual Hard Drives
The third option for performing a storage migration is to move only the Virtual
Hard Disk files. This option is useful if you want to free up some storage
space by moving the virtual hard disk files, but want to keep the other virtual
machine components in their current location. You can complete this type of
storage live migration by following these steps:
1. Open the Hyper-V Manager.
2. Right-click on the virtual machine for which you wish to perform a storage
migration, and select the New command from the right-click menu.
3. When the Move wizard launches, click Next to bypass the wizard’s
Welcome screen.
4. Choose the option to move the virtual machine’s storage, and click Next.
5. Choose the option to Move Only the Virtual Machine’s Virtual Hard Disks
(Figure 3.50).
120
Understanding Hyper-V in Windows Server 2012
Figure 3.50
Choose the option to move only the virtual machine’s Virtual Hard Disks.
6. Click Next.
7. Select the Virtual Hard Disks that you want to move (Figure 3.51)
and click Next.
Figure 3.51
Select the Virtual Hard Disks that you wish to move.
121
Understanding Hyper-V in Windows Server 2012
8. Specify the location to which you wish to move the Virtual Hard Disks
and click Next (Figure 3.52).
9. Verify the information on the summary screen and click Finish.
Figure 3.52
Enter the path where the virtual hard disk should be stored.
122
Understanding Hyper-V in Windows Server 2012
Chapter 4
Managing Virtual
Machine Failover
The previous chapters show you how to build clustered
Hyper-V deployments and how to migrate virtual
machines within those environments. However, facilitating
live migrations is only part of a Hyper-V cluster’s job.
A cluster also has to keep virtual machines running, even
if the server on which a virtual machine is hosted were
to fail.
This chapter discusses various aspects of failover planning.
In this chapter you will learn about failover testing,
anti‑affinity rules and virtual machine prioritization.
123
Understanding Hyper-V in Windows Server 2012
Virtual machine failover
One of the big problems with server virtualization is that the virtualization
host (the Hyper-V server) can become a single point of failure that can impact
multiple virtual workloads.
In a physical datacenter, the failure of a single server is usually an inconvenience,
but it is rarely considered catastrophic. This isn’t necessarily the case in
a virtual datacenter.
In a virtual datacenter, a physical server running Hyper-V hosts has multiple
virtualized workloads. If this one, single physical server were to fail, all of the
virtual machines that are running on that server will fail as well – unless, of
course, the server is operating as a node within a failover cluster. Clustering is
what keeps virtual machines running, even if the physical hardware fails.
Failover testing
As you have no doubt seen in the previous chapters, there is a lot of work
that goes into building a Hyper-V cluster. However, none of the hard work
and expense means very much if your cluster fails to keep your virtual
machines running when a hardware failure occurs. Of course you probably
don’t want to wait for a disaster to happen in order to find out if your cluster
is working or not. It’s better to test the cluster ahead of time.
Failover cluster testing can be tricky in a production environment because
you don’t want to jeopardize your production virtual machines in the testing
process. And it’s never a good idea to test your clustering solution by walking
through the datacenter and randomly yanking power cords out of clustered
hosts. Even though this type of testing makes for an amusing story, it is hardly
a recommended method.
Microsoft gives you a few different methods of testing failover within your
cluster. However, all of these tests tend to focus on the cluster at a high level.
Microsoft does not provide a method for testing the failover of an individual
virtual machine.
Validation testing
The first type of testing that you can perform is a cluster validation test. If this
sounds familiar, it is probably because you performed a validation test when
you were preparing to build the failover cluster.
Even though you may think of a validation test as a tool to use in preparation
for building a cluster, you can perform these types of tests against a cluster
that has already been established. The reason why this might be helpful
is because cluster configurations tend to change over time and validation
testing will help you spot any configuration problems that might exist within
your cluster.
You can perform validation testing either through the Failover Cluster Manager
or through PowerShell. To perform validation testing using the Failover Cluster
Manager, follow these steps:
1. Open the Server Manager.
124
Understanding Hyper-V in Windows Server 2012
2. Select the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager opens, select the listing for your
cluster within the console tree.
4. Click on the Validate Cluster link, found in the Actions pane (Figure 4.1) .
Figure 4.1
Click on the Validate Cluster link.
5. When the Validate a Cluster Wizard begins, click Next to bypass
the wizard’s Welcome screen.
6. Choose the option to run only the tests that you select (Figure 4.2).
Figure 4.2
Choose the option to run only the tests that you select.
7. Click Next.
8. On the following screen, select the tests that you want to run (Figure 4.3).
You can select entire categories of tests (such as Inventory, Network, or
System Configuration), or you can expand a category and select individual
tests within that category.
125
Understanding Hyper-V in Windows Server 2012
Figure 4.3
Select the tests that you want to run.
9. Click Next.
10. The following screen displays your cluster disk (assuming that your cluster
uses a Cluster Shared Volume) and indicates that you can select the cluster
disk if you want to include it in the validation testing (Figure 4.4). However,
you should only run the tests against your cluster disk if the Cluster
Shared Volume has been stopped. Otherwise, the testing can cause virtual
machines to fail.
Figure 4.4
Do not select the cluster disk if your Cluster Shared Volume is in use!
126
Understanding Hyper-V in Windows Server 2012
11. Click Next.
12. Take a moment and look through the confirmation screen to make sure
that you have selected the proper tests.
13. Click Next to begin the tests.
14. When the tests complete, click the View Report button to view
the validation report (Figure 4.5).
15. Click Finish.
Figure 4.5
Click the View Report button to view the validation report.
Validation testing through PowerShell
Just as you can perform validation testing using the Failover Cluster Manager,
you can also validate clusters using PowerShell. PowerShell testing is very
flexible and you are free to pick and choose the tests that you want to run.
Validation testing with PowerShell is based on the Test-Cluster cmdlet. You can
perform comprehensive validation testing against all of your cluster nodes by
simply entering the Test-Cluster cmdlet (Figure 4.6). Keep in mind, however,
that you must not test Cluster Shared Volumes that are actively being used.
127
Understanding Hyper-V in Windows Server 2012
Figure 4.6
The Test-Cluster cmdlet can be used for comprehensive cluster validation testing.
When you first enter the Test-Cluster cmdlet, PowerShell may appear to
lock up. After several seconds you should see the tests begin, as shown in
Figure 4.6.
When the validation testing completes, you will see a message that refers to
a validation report (Figure 4.7). The validation report file is located in the C:\
Windows\Cluster\Reports folder. You can open the validation reports using
Internet Explorer, as shown in Figure 4.8.
Figure 4.7
The test’s output is written to a validation report.
Figure 4.8
Validation reports are displayed in Internet Explorer.
128
Understanding Hyper-V in Windows Server 2012
Keep in mind that the validation report shown in the figure above was based
on a comprehensive set of cluster tests. It is possible to exercise a high degree
of granular control over the testing process. Using PowerShell, you can run
specific validation tests, exclude certain validation tests and direct the testing
process to specific cluster nodes.
The trick to using PowerShell to control the validation tests is to retrieve a list
of the test names. Once you have a list of the test names (as referenced by
PowerShell) you can begin to include or exclude specific tests. To get a list of all
of the test names, enter the following command (Figure 4.9):
Test-Cluster – List
Figure 4.9
You can retrieve a list of all of the validation tests.
Once you have a list of test names, it is easy to include or exclude individual
tests. For example, suppose that you want to perform all of the validation tests
except for those related to storage. You can do so by entering the following
command:
Test-Cluster –Ignore Storage
Similarly, if you only want to run the system drivers test, you can enter
a command like this one (Figure 4.10):
Test-Cluster –Include “List System Drivers”
Figure 4.10
You can tell PowerShell to run specific tests.
129
Understanding Hyper-V in Windows Server 2012
You can also use PowerShell to specify the cluster nodes to include in
the validation tests. For example, suppose that you want to run the validation
tests against nodes named Lab1, Lab2, and Lab3 (Figure 4.11). To do so, you
can use the following command:
Test-Cluster –Node Lab1,Lab2,Lab3
Figure 4.11
You can run validation tests against individual cluster nodes.
Cluster resource testing
The second type of cluster testing you can perform is called cluster resource
testing. Cluster resource testing lets you see how your cluster would behave
if a specific resource failed. Unfortunately, this type of testing is somewhat
limited and there isn’t much documentation available from Microsoft
pertaining to it.
There are three important things that you need to know about cluster resource
testing prior to trying it:
1. Cluster resource testing simulates the failure of a cluster resource, so if you
do not perform the tests carefully you could cause an outage.
2. You can only test components that Microsoft defines as cluster resources.
You will find out how to get a list of these components below.
3. Often the name that Windows assigns to a cluster resource is different
from the name that you give to the resource. You can use cluster resource
testing to find out what would happen if a virtual machine fails, but you
won’t be able to reference the virtual machine by its usual name.
With that said, cluster resource testing is based on the use of the TestClusterResourceFailure cmdlet. The syntax for this cmdlet is simple. You only
have to specify the name of the resource that you want to test. The trick is
to figure out which resources are available for testing and the names that
Windows uses for those resources.
The easiest way to deal with this challenge is to enter the Get-ClusterResource
cmdlet. When you do this, PowerShell displays a list of the cluster resources
(Figure 4.12).
130
Understanding Hyper-V in Windows Server 2012
Figure 4.12
Use the Get-ClusterResource cmdlet to create a list of cluster resources.
Notice in the figure above that the last item on the list is Virtual Machine VM3.
This virtual machine’s name is VM3, but for the purpose of cluster resource
testing, the virtual machine must be referred to as Virtual Machine VM3. If
you want to see what would happen if the virtual machine fails, you can enter
the following command (Figure 4.13):
Test-ClusterResourceFailure “Virtual Machine VM3”
Figure 4.13
You can use PowerShell to simulate the failure of a virtual machine.
If you look at the Failover Cluster Manager, you can see that the virtual
machine can actually go down as a result of the test (Figure 4.14). Running
the test once against a virtual machine causes the virtual machine to go down
for a moment and then come back up. However, running the test twice usually
takes the virtual machine completely offline until you right-click on the virtual
machine and choose the Start option from the right-click menu.
Figure 4.14
Virtual machine failure testing takes the virtual machine offline.
131
Understanding Hyper-V in Windows Server 2012
For the most part, cluster resource failure testing is limited to the items on
the list of cluster resources (Figure 4.12). The big exception, however, is that you
can also test cluster disks. Suppose for example that you want to test the failure
of a disk named Cluster Disk 1 (Figure 4.12). You can do so by entering the
following command:
Test-ClusterResourceFailure –Name “Cluster Disk 1”
Figure 4.15
You can use the Test-ClusterResourceFailure cmdlet to test cluster disk failures.
Failover testing
The third type of testing you can do with regard to your cluster is failover
testing. Failover testing simulates the failure of an active cluster node and tests
the cluster’s ability to failover to another node in the cluster.
Unfortunately, Microsoft does not provide a mechanism for testing the failover
of an individual virtual machine. Instead, failover testing occurs at the cluster
level. To perform a failover test, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager appears, navigate through the console
tree to Failover Cluster Manager | <your cluster> (Figure 4.16) .
132
Understanding Hyper-V in Windows Server 2012
Figure 4.16
Select your cluster within the Failover Cluster Manager.
4. Click on the More Actions link, found in the Actions pane and then click
on the Simulate Failure link (Figure 4.17).
Figure 4.17
Click on the Simulate Failure option.
133
Understanding Hyper-V in Windows Server 2012
5. Windows will display a warning message telling you that simulating
afailure could cause clustered roles (in this case virtual machines) to be
moved to another cluster node, and that service could potentially be
interrupted. Click Yes to move forward with the test.
6. You can watch the failover happen in the Cluster Core Resources pane,
which is located in the lower, middle portion of the Failover Cluster
Manager (Figure 4.18).
Figure 4.18
You can watch the failover occur in the Cluster Core Resources pane.
Anti-affinity rules
In multi-tenant environments, it is sometimes necessary to configure certain
virtual machines so that they never reside on the same host server. For
example, if your organization were hosting virtual machines for both Coke
and Pepsi, you would not want the two companies’ virtual machines to reside
on a common host server.
It is relatively easy to keep virtual machines separate from one another when
you initially create the virtual machines. However, virtual machines are anything
but static and the chances of a virtual machine remaining on the same Hyper-V
host for an indefinite period of time are slim.
If you have virtual machines that need to be kept separate, you can reduce
the chances of those virtual machines ever ending up on a common host by
using anti-affinity rules. Anti-affinity rules prevent virtual machines that must
remain separate from failing over to a common host.
Unfortunately, anti-affinity rules are not exactly easy to work with. These
rules can only be established through PowerShell, and the process is not
very intuitive.
The key to understanding how the process works is to understand that
for every clustered virtual machine, there is a corresponding cluster group.
Each cluster group uses the same name as the virtual machine for which
it was created. Anti-affinity rules are applied to cluster groups, not to
virtual machines.
Like other types of objects in PowerShell, cluster groups have a number of
different properties (Figure 4.19). To see a list of the cluster group properties,
enter the following command:
Get-ClusterGroup <group name> | Select-Object *
134
Understanding Hyper-V in Windows Server 2012
Figure 4.19
Cluster groups are made up of a number of properties.
As you look at the properties in the screen capture above, you will notice that
the third property from the bottom of the list is named AntiAffinityClassNames.
Creating an anti-affinity rule involves assigning a value to this property.
Normally you could modify this type of value by using a command like this:
Get-ClusterGroup <virtual machine name> | Set-ClusterGroup –
AntiAffinityClassNames <value>
However, there is just one problem with the command shown above—there
is no Set-ClusterGroup cmdlet. The fact that such a command does not exist
is a safety precaution—if a Set-ClusterGroup cmdlet did exist, you could
potentially destroy a virtual machine if you used the cmdlet incorrectly.
Since you can’t use Get-ClusterGroup and Set-ClusterGroup, you have to use
a completely different approach to modifying the AntiAffinityClassNames
property.
Unfortunately, Windows PowerShell does not contain the code for managing
the AntiAffinityClassNames property. However, you can download a PowerShell
module that makes it possible to directly manipulate this property. In case
you are not familiar with the concept of a PowerShell module, it is basically
a collection of PowerShell cmdlets that can be bolted on to the core cmdlet set.
You can download the PowerShell Module for Configuring AntiAffinityClassNames
in Failover Clustering at: http://gallery.technet.microsoft.com/PowerShellmodule-for-16242485. This module is designed for use with Windows Server
2008 R2, but it works with Windows Server 2012 as well.
The download consists of a ZIP file. You will need to download the ZIP file
and extract its contents to the server’s hard disk. The path that you use is up to
you, but you will have to enter the full path into PowerShell, so it is beneficial
to use a relatively simple path. For demonstration purposes this example places
the extracted files into a folder named C:\Modules.
135
Understanding Hyper-V in Windows Server 2012
Once you have extracted the zip file’s contents, you’ll need to import
the module into PowerShell. Note that importing a module is not a permanent
operation. The module only remains imported for as long as PowerShell is
open. If you need to use the module again at a later time, you will have to
import it again.
Before you can import the module, you will have to configure your server’s
execution policy to allow PowerShell scripts to be run. The easiest way to do
this is to enter the following command:
Set-ExecutionPolicy Unrestricted
This command allows PowerShell to run any PowerShell script, regardless
of where it came from (Figure 4.20). Obviously, there are some security
implications associated with allowing unrestricted access to scripts, as
explained in the text shown below (Figure 4.20). If you are concerned about
security, you can set the execution policy back to Restricted when you finish
working with the AntiAffinityClassNames by using the Set-ExecutionPolicy
Restricted cmdlet.
Figure 4.20
You must configure the execution policy to allow PowerShell scripts to be run.
With that said, you can use the following command to import the module
(assuming that the module resides in C:\modules):
Import-Module C:\Modules\AntiAffinityClassNames
When you execute the command listed above, you will see several prompts
asking if you want to allow the script to run (Figure 4.21). You must run each of
these scripts in order to successfully import the module.
Figure 4.21
You must import the AntiAffinityClassNames module before you can use it.
As previously mentioned, a PowerShell module adds cmdlets to the built-in
cmdlet set. If you would like to see a list of the new cmdlets that were added,
enter the following command (Figure 4.22):
Get-Command –Module AntiAffinityClassNames
136
Understanding Hyper-V in Windows Server 2012
Figure 4.22
The AntiAffinityClassNames module adds three new cmdlets to PowerShell.
Now that all of the necessary components are in place, you can begin working
with anti-affinity rules. The basic idea behind these rules is that certain servers
should never reside on the same hosts. You can specify these servers by
adding a value to the AntiAffinityClassNames parameter. Servers with the same
AntiAffinityClassNames parameter will not normally fail over to a common host.
A more concrete example of how this works is a situation in which
an organization has multiple virtualized domain controllers. You would never
want to be in a situation in which all of your domain controllers failed over
to the same host. That being the case, you could add the phrase “Domain
Controller” to each domain controller’s AntiAffinityClassNames parameter
to indicate that each server that uses this tag is a domain controller and that
each domain controller should reside on a separate host. To be perfectly
clear, the “Domain Controllers” value is just an example—you can call your
anti‑affinity values anything that you want.
Setting up anti-affinity rules in this manner does not guarantee that the virtual
machines will never be hosted on the same server. If the cluster is ever put
into a situation where there aren’t enough remaining cluster nodes to facilitate
the requirements of the anti-affinity rules, Windows will place the virtual
machines wherever it can. The assumption is that it is more important to keep
the virtual machines running than it is to keep them separated.
Now you can configure anti-affinity rules by using the Set-AntiAffinityClassNames
cmdlet. This cmdlet requires you to specify the name of the cluster, the cluster
group to which the rule should apply (the cluster group name is the same as
the virtual machine name), and the value that you want to assign. Suppose, for
example, that your cluster is named HyperVCluster and that you want to assign
an AntiAffinityClassNames value of “Domain Controller” to a virtual machine
named VM3. To do so, use the following command:
Set-AntiAffinityClassNames –Cluster HyperVCluster –ClusterGroup VM3 –
Value “Domain Controller”
It is worth noting that the Set-AntiAffinityClassNames cmdlet sometimes
has trouble recognizing a cluster name. You may receive an error telling you
to check the spelling of the cluster name. If that happens, enter the GetAntiAffinityClassNames cmdlet (Figure 4.23). By doing so, you might find that
the cluster name is listed as localhost rather than by its designated name.
137
Understanding Hyper-V in Windows Server 2012
Figure 4.23
The cluster name is sometimes listed as localhost.
When you successfully assign a value to the AntiAffinityClassNames property,
PowerShell does not acknowledge the success of the operation. The easiest
way to confirm that the operation was successful is to enter the GetAntiAffinityClassNames cmdlet (Figure 4.24).
Figure 4.24
Use the Get-AntiAffinityClassNames cmdlet to verify the success of the operation.
Virtual machine prioritization
Failover clusters are great because if a cluster node fails, the virtual machines
can fail over to another node in the cluster where they continue to run.
Sometimes, however, the failover process fails because of insufficient
system resources.
Most Hyper-V failover clusters do not use empty cluster nodes that are sitting
idle, waiting for a failure to happen. More often, each cluster node hosts a
number of virtual machines. If a failure occurs, the Failover Cluster Service will
attempt to move the virtual machines from the failed node to another cluster
node where those virtual machines can continue to run. However, if the node
was already hosting some virtual machines prior to the failure, then that server
may not have enough memory or CPU resources to host its own workload plus
all of the virtual machines from the failed cluster node.
Unfortunately, there is no magic trick that you can use to make the cluster
node handle all of those virtual machines from the failed cluster node. Servers
only have so much memory and when all of that memory has been allocated,
the server will be unable to host any additional virtual machines.
Because Windows can’t expand a cluster node’s capacity so that it can handle
more virtual machines, Windows instead lets you prioritize virtual machines.
In any organization there are some virtual machines that are more important
than others. For example, your mail server is probably more important than
a redundant domain controller.
138
Understanding Hyper-V in Windows Server 2012
By prioritizing your virtual machines, you can make sure that the most
important virtual machines continue to function in a failover situation.
Windows will start the highest priority virtual machines first and lower priority
virtual machines in sequence until the server runs out of memory or other
resources.
Setting a virtual machine’s priority is easy. To do so, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager starts, select the Roles container.
4. Right-click on the virtual machine that you want to prioritize and choose
the Change Startup Priority command from the right-click menu
(Figure 4.25).
5. Specify the virtual machine’s priority.
Figure 4.25
Specify the virtual machine’s startup priority.
As you look at the figure above, you will notice that the Failover Cluster
Manager has a Priority column that displays each virtual machine’s priority.
Every virtual machine has a default priority of Medium, but you can raise
or lower that priority based on the virtual machine’s importance.
Setting the preferred owners
Some organizations might prefer to have virtual machines running on certain
hosts. For example, if you have a large database application, you would
probably want that application to run on the host that has the fastest CPU.
Hyper-V allows you to set priorities on which physical hosts your virtual
machines run. To specify a preferred host, follow these steps:
1. Open the Server Manager.
2. Choose the Failover Cluster Manager command from the Tools menu.
3. When the Failover Cluster Manager opens, select the Roles container.
139
Understanding Hyper-V in Windows Server 2012
4. Right-click on a clustered virtual machine for which you want to specify
a preferred host server and select the Properties command from
the right‑click menu.
5. When the Core Properties dialog box appears, select the checkbox for
the virtual machine’s preferred host server (Figure 4.26).
Figure 4.26
Hyper-V allows you to specify a preferred host server for any clustered virtual machine.
Although Microsoft makes it easy to specify a preferred host, there are two
things that you should know about host server prioritization. First, you can
specify multiple preferred servers by selecting the checkboxes for each
preferred cluster node. Use the Up and Down buttons shown in the figure
above to arrange the list of cluster nodes based on your preferred priority.
Second, host prioritization is not guaranteed. If a virtual machine’s preferred
host is offline or lacks the capacity to host a virtual machine, the virtual
machine will be hosted on a cluster node other than the preferred node.
Failover rules
The Failover Cluster Service allows you to set some ground rules for the way
that virtual machines failover to other cluster nodes. These rules are all
controlled through a dialog box within the Failover Cluster Manager. To access
this dialog box, follow these steps:
1. Open the Server Manager.
2. Select the Failover Cluster Manager option from the Tools menu.
3. When the Failover Cluster Manager opens, select the Roles container.
4. Right-click on a clustered virtual machine.
5. Select the Properties command from the right-click menu.
6. When the virtual machine’s properties sheet appears, select the Failover
tab (Figure 4.27).
140
Understanding Hyper-V in Windows Server 2012
Figure 4.27
Failover is controlled through the settings found on the Failover tab.
Note that the Failover tab is divided into two sections. The first section allows
you to define the maximum number of failovers that can occur within a given
period of time. The idea is that if a virtual machine fails over repeatedly, there
is probably a serious problem with that virtual machine or with the cluster
and it might be better to simply take the virtual machine offline and put it
into a failed state rather than allow it to keep failing over. By default, failures
are capped at two failures within a six-hour period, but you can adjust these
settings based on your needs.
The lower portion of the dialog box lets you control whether or not
the virtual machine will be allowed to fail back to the server on which it was
originally hosted. By default, automatic failback is disabled. However, you
can enable automatic failback and configure it to happen immediately or on
a scheduled basis.
In most cases it is best to leave automatic failback disabled. If a failover
occurred, a problem exists that caused the failover, and you don’t want
your virtual machines automatically failing back to a cluster node that has
an unresolved problem.
141
Understanding Hyper-V in Windows Server 2012
Chapter 5
PowerShell
Management
In Windows Server 2008 and 2008 R2, Microsoft allowed
many aspects of the Windows operating system to be
managed through PowerShell. Because PowerShell was
relatively new, however, there were certain operating
system components (including Hyper-V) that could not
be managed through PowerShell. Microsoft eventually
released a PowerShell module for Hyper-V, but this
module had to be downloaded separately. Thankfully,
the Windows Server 2012 version of Hyper-V includes
native PowerShell management capabilities. It is the goal
of this chapter to familiarize you with the various ways
in which Hyper-V can be managed through PowerShell.
142
Understanding Hyper-V in Windows Server 2012
Syntax simplification
Before discussing PowerShell management for Hyper-V, there is some
good news. While developing Windows Server 2012, Microsoft realized that
non‑developers often struggled with PowerShell. In spite of what the marketing
folks might say, the syntax for various PowerShell commands was often
complex and completely non-intuitive. Thankfully, Microsoft decided to simplify
the PowerShell syntax—especially as it relates to the Where-Object and
ForEach-Object cmdlets.
To show you an example of the way that the syntax has been simplified,
imagine that you want to see a list of all of the processes that are running on
the local Hyper-V host server. Prior to Windows Server 2012, you would have
had to use this command:
Get-Process | ForEach {$_.Name}
The Windows Server 2012 version of PowerShell is backward compatible
with the previous version, so you can still use this style of command (this is
important if you want to continue using older scripts). However, Windows
Server 2012 also allows you to enter commands in a simplified manner. For
example, the command shown above can be simplified as:
Get-Process | ForEach Name
This same simplification also applies to operations in which you use operators
to filter the result set. For example, prior to Windows Server 2012, to see a list
of all of the processes using more than 500 handles, you would have had to use
the following command:
Get-Process | where {$_.Handles –gt 500}
In Windows Server 2012, this command can be simplified as:
Get-Process | Where Handles –gt 500
143
Understanding Hyper-V in Windows Server 2012
Attaching to a Hyper-V server
The first skill you must master with regard to managing Hyper-V from
PowerShell is that of attaching to a remote server. If you plan to manage
Hyper-V through PowerShell by using the local server console, then you won’t
have to worry about establishing a remote PowerShell connection. You can
simply open a PowerShell window and enter the various cmdlets without
having to do anything special. However, if you need to manage a remote host,
you will first need to establish a session with that host.
There are a few different ways to use a PowerShell session to control a remote
Hyper-V host. One method involves using the Enter-PSSession cmdlet. To use
this method, enter the Enter-PSSession cmdlet and append the name of
the server that you want to attach to. Any commands that you run from this
point on will execute on the remote server, but the results will be displayed
in the local console. You can end the session by entering the Exit-PSSession
cmdlet. For example, to establish a session with a server named Lab2,
execute the Get-VM cmdlet, and then terminate the session, you would use
these commands:
Enter-PSSession Lab2
Get-VM
ExitPSSession
Notice in the screen capture (Figure 5.1) that the PowerShell prompt changes
to reflect the name of the server that you are attached to.
Figure 5.1
You can use the Enter-PSSession cmdlet to establish a remote PowerShell session.
Another method is to use the Invoke-Command cmdlet to execute a single
command on a remote host (Figure 5.2). The trick is to specify the computer
name. You can even specify multiple computer names if you separate them
by commas. The actual command that you send to the remote machines must
appear in braces. For example, to send the Get-VM command to computers
named Lab1, Lab2 and Lab3, you would enter the following command:
Invoke-command –ComputerName Lab1, Lab2, Lab3 {Get-VM}
144
Understanding Hyper-V in Windows Server 2012
Figure 5.2
You can use the Invoke-Command cmdlet to remotely execute a PowerShell command.
Keep in mind that these are the simplest methods of establishing a remote
PowerShell session. Things can become more complex if you need to enter
an alternative set of permissions or if you need to modify the execution
policy to allow scripts to be run. For example, the block of PowerShell listed
below is used to manage an Office 365 environment through PowerShell.
Although Office 365 is beyond the scope of this book, this example illustrates
the point that there are more complex methods of establishing remote
PowerShell connectivity.
Set-ExecutionPolicy RemoteSigned
Import-Module MSOnline
$Cred = Get-Credential
$MySession = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.outlook.com/powershell -Credential $Cred
-Authentication Basic -AllowRedirection
Import-PSSession $MySession
Querying virtual machines
One of the most basic (but useful) things that you can do with PowerShell
involves performing various queries against virtual machines. The simplest of
these queries involves using the Get-VM cmdlet. Entering this cmdlet returns
a list of all of the virtual machines that are present on the host (Figure 5.3).
Along with the name of each virtual machine, you can also see the virtual
machine’s state (whether or not it is running) along with its CPU usage,
memory assigned, up time and status.
145
Understanding Hyper-V in Windows Server 2012
Figure 5.3
The Get-VM cmdlet returns a list of the virtual machines that are present on the host.
Notice in Figure 5.3 that the Get-VM cmdlet returns virtual machine information
from the local server. Had we established a PowerShell session with a remote
server, virtual machine information from the remote server would have been
returned instead. If you need to perform a Get-VM query against a remote
server, however, it may not always be necessary to establish a session with the
server. Remote sessions are most useful when you need to redirect PowerShell
so that all operations are performed against the remote host instead of
the local host. If you simply need to retrieve a bit of information from the
remote host, you can often do so by using a standard PowerShell cmdlet and
appending the name of the remote server.
To see how this works, imagine that you want to see a list of the virtual
machines residing on a host named Prod1 (Figure 5.4). You can accomplish this
by entering the following command:
Get-VM –ComputerName Prod1
Figure 5.4
You can get a list of the virtual machines that reside on a specific host.
Of course, the list of virtual machines that are running on a specific host could
potentially be really long. Often you might be more interested in viewing
the state of a specific virtual machine rather than seeing a list of every virtual
machine that exists on a host server. In this case, you can append a virtual
machine name directly to the end of the Get-VM cmdlet (Figure 5.5). For
example, to view the current state of a VM named Lab-DC you can enter
this command:
Get-VM Lab-DC
Figure 5.5
You can retrieve information for a specific virtual machine.
146
Understanding Hyper-V in Windows Server 2012
Just as you can use the Get-VM cmdlet to retrieve basic information about
virtual machines, you can use the Get-VMHost cmdlet to access information
about host servers (Figure 5.6). Entering the Get-VMHost cmdlet by itself
returns the name of your host server along with its logical processor count,
memory capacity and whether or not the virtual machine is configured to allow
virtual machine migrations.
Figure 5.6
The Get-VMHost cmdlet retrieves information about a host server.
It is also possible to use the Get-VMHost cmdlet to retrieve information about
multiple host servers at the same time. Simply append the names of the host
servers that you want to query. Host server names should be separated
by commas (Figure 5.7). For example, the command might look something
like this:
Get-VMHost Lab1,Lab2,Lab3,Prod1,Prod2
Figure 5.7
You can query multiple host servers through a single command.
Filtering the output
In the previous section, you saw that it is possible to use the Get-VM
(Figure 5.8) and the Get-Host cmdlets to retrieve basic information about
virtual machines and host servers. Often, however, you might need to access
more detailed information than what these cmdlets provide by default.
Fortunately, there are a number of ways to accomplish this.
Figure 5.8
You can use the Get-VM cmdlet to retrieve virtual machine information.
147
Understanding Hyper-V in Windows Server 2012
One of the nice things about PowerShell is that it allows you to use attributes
and operators to filter a cmdlet’s output. Some of the commonly used
operators include:
Equal To
-EQ
Or
-OR
And
-AND
Like
-Like
Greater Than -GT
Less Than
-LT
You can combine these operators with object attributes to retrieve very
granular information about your host servers and virtual machines.
One of the most basic examples of output filtering involves filtering virtual
machines by name. For example, entering the Get-VM cmdlet on the host Lab1
returns listings for a number of virtual machines. On this server the name of
each virtual machine reflects the virtual machine’s purpose. For example, virtual
machines starting with LAB15 are lab machines related to Microsoft’s wave 15
product release (Office 15, SharePoint 15, Exchange 15, etc.).
With this in mind, it might occasionally be necessary to get a list of the virtual
machines that are related to wave 15 testing. In this situation, the Like operator
could prove to be very handy. You can use the Like operator to list values that
are similar to a target value. For instance, you can list all of the virtual machines
that have names starting with Lab15 (Figure 5.9) by using the following cmdlet:
Get-VM | Where Name –Like ‘Lab15*’
Figure 5.9
You can use filtering to narrow down the list of virtual machines.
Being able to filter virtual machines by name is nice, but this is not the only
type of filtering you can do. It is also possible to filter on things like a virtual
machine’s state. For instance, if you want to see which virtual machines are
currently powered off (Figure 5.10), you can use the following command:
Get-VM | Where State –EQ ‘Off’
Figure 5.10
You can filter based on a virtual machine’s state.
148
Understanding Hyper-V in Windows Server 2012
Obviously it’s handy to be able to see a list of the virtual machines that are
powered off, but remember that the command shown above only looks
at the current host server. What if you wanted to see a list of the running virtual
machines across multiple hosts? To accomplish this, you would simply add
the –ComputerName switch and the names of the hosts that should be
included in the query (Figure 5.11). The command might look something
like this:
Get-VM –ComputerName Lab1,Lab2,Lab3,Prod1,Prod2 | Where State –EQ
‘Running’
Figure 5.11
A filtered output can contain data from multiple Hyper-V host servers.
What about clusters?
So far the topic of filtering has assumed that the virtual machines are running
on standalone hosts. However, virtual machine queries can also be very useful
in clustered environments. Suppose, for example, that you want to see a list of
all of your clustered virtual machines (Figure 5.12). You can do so by entering
the following command:
Get-ClusterGroup | Where GroupType –EQ ‘VirtualMachine’ | Get-VM
Figure 5.12
You can use PowerShell for cluster management.
This technique becomes most useful when you apply multiple filters together.
If you look at the previous screen capture you will notice that one clustered
virtual machine is running and another is not. If this were a production
environment with lots of virtual machines, it might be useful to compile a list of
the clustered virtual machines that were not running (Figure 5.13). You could do
this by entering the following command:
Get-ClusterGroup | Where GroupType –EQ ‘VirtualMachine’ | Get-VM | Where
State –EQ ‘Off’
Figure 5.13
You can create a list of clustered virtual machines that are not currently running.
149
Understanding Hyper-V in Windows Server 2012
In a clustered environment it isn’t just important to keep virtual machines
running, it is also important to keep track of resource utilization. You can use
a similar technique to the one that was just demonstrated to keep track of
virtual machine memory usage within the cluster. For example, to create a list
of all of the clustered virtual machines that are using more than a gigabyte of
memory (Figure 5.14), you can use this command:
Get-ClusterGroup | Where GroupType –EQ ‘VirtualMachine’ | Get-VM | Where
MemoryAssigned –GT ‘1073741825’
Figure 5.14
You can use PowerShell to determine which VMs are consuming excessive system resources.
It is worth noting that even though PowerShell displays the memory in
megabytes in this case, you must enter the MemoryAssigned value in bytes.
Getting more information
So far, this chapter has discussed various filtering techniques, but often you
may need more detailed information than what the various commands provide
by default. The good news is that the Get-VM and the Get-VMHost cmdlets
only display a small subset of the information that is actually available and it
is easy to customize the commands so that just the information you need
is displayed.
In PowerShell, VM and VMHost both represent objects. Objects contain
a collection of attributes. Therefore, the key to customizing the command
output is controlling which attributes are displayed. To see the attributes
that are available for the Get-VM cmdlet (Figure 5.15), enter the following
command:
Get-VM Lab-DC | FL *
150
Understanding Hyper-V in Windows Server 2012
Figure 5.15
A wealth of information is available for each virtual machine.
This command displays all of the available attributes in list format. Pay
attention to the attribute names because you can use these names to
customize the output or to apply filters. Similarly you can view all of the
attributes that are available within the Get-VMHost cmdlet (Figure 5.16) by
entering this command:
Get-VMHost | FL *
151
Understanding Hyper-V in Windows Server 2012
Figure 5.16
You can use the Get-VMHost cmdlet to retrieve host server information.
As you can see, there is a lot of information available both for virtual machines
and for host servers. But what can you do with all of this information?
For starters, you can control the output of the Get-VM or the Get-VMHost
cmdlets (Figure 5.17). For example, suppose that you want to see each virtual
machine’s name, the name of the host on which the virtual machine currently
resides and whether or not the virtual machine is clustered. You can accomplish
this by entering the following command:
Get-VM | FT VMName, ComputerName, IsClustered
Figure 5.17
You can control the output of the Get-VM or the Get-VMHost cmdlets.
Of course, you output the values of any of the available attributes and you can
also use the various attributes with operators such as –Like, -And, -GT, etc.
to achieve a filtered output.
It is worth noting that Microsoft provides a number of cmdlets that you can
use as shortcuts to retrieve very specific information about virtual machines.
For example, you can use the Get-VMMemory cmdlet to retrieve a virtual
machine’s memory configuration. Likewise, you can use the Get-VMProcessor
cmdlet to view a virtual machine’s virtual CPU configuration.
152
Understanding Hyper-V in Windows Server 2012
Reporting
In the previous section you learned how to modify the Get-VM
and the Get‑VMHost cmdlets to achieve the desired output, but you can
actually take things a step further and use PowerShell as a reporting engine.
You can use PowerShell to create CSV, Text and even HTML files.
Lists and tables
Before moving on to the creation of these file types, there is one more aspect
of the output formatting to discuss. In the previous sections, the codes FL 9
(Format-List) and FT (Format-Table) were used. Formatting a command’s
output as a list (Figure 5.18) displays the information vertically. This is the most
appropriate format for viewing large amounts of information on screen. Tables
(Figure 5.19) display information horizontally. This table format is best for
looking at multiple results, such as a listing of virtual machines.
Figure 5.18
Lists display information vertically.
153
Understanding Hyper-V in Windows Server 2012
Figure 5.19
Tables display data horizontally.
It is fine to use FT and FL to view a command’s output on screen, but if you
plan to write the output to a CSV or HTML file, this will not work. Instead,
you will have to replace FT or FL with the Select-Object cmdlet (Figure 5.20),
followed by the attributes that you want to display. For example, you might use
a command like this one:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status
Figure 5.20
Often, it is necessary to use the Select-Object cmdlet to specify what data to include
in a report.
154
Understanding Hyper-V in Windows Server 2012
CSV files
CSV files are almost always created in table format. CSV files are useful
for outputting large amounts of information in a format that can be read
by Microsoft Excel or imported into a database. You can create a CSV file by
appending the Export-CSV cmdlet to whatever command you are using. It
is worth noting, however, that you must manually specify the attributes to
include in the output. For example, to create a CSV file containing a listing of
your virtual machines, their state, the host, whether or not the virtual machine
is clustered, and the virtual machine’s uptime and status (Figure 5.21), you can
enter this command:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | Export-CSV C:\Data\VMs.csv
Figure 5.21
You can choose which fields to export to a CSV file.
Once created, you can open the CSV in Microsoft Excel (Figure 5.22).
Figure 5.22
You can open CSV files in Microsoft Excel.
Text files
The process of creating a text file is similar to that of creating a CSV file,
but PowerShell is a bit more forgiving when it comes to creating text files.
You don’t have to use the Select-Object cmdlet and can instead use FT or FL.
Rather than using the Export-CSV cmdlet, you will use the Out-File cmdlet.
Other than that, the commands are identical. For example, to write a list of
virtual machines to a text file (Figure 5.23), you can use this command:
Get-VM | FT VMName, State, ComputerName, IsClustered, UpTime, Status |
Out-File C:\Data\VMs.txt
155
Understanding Hyper-V in Windows Server 2012
Figure 5.23
You can write PowerShell data to a text file.
Notice in Figure 5.23 that you can view the contents of the newly created
text file by entering the Type command, followed by the path and filename
of the text file. Of course, you can also open the file in Notepad or any other
text editor.
HTML reports
The process of creating an HTML report is similar to that of creating a text
file—both use the Out-File cmdlet. However, to create an HTML report,
you need to add the ConvertTo-HTML cmdlet. For example, to write a list of
your virtual machines to an HTML file, use this command:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | ConvertTo-HTML | Out-File C:\Data\VMs.htm
Just for fun, you can modify this command so that it creates the report
and automatically opens it in Internet Explorer (Figure 5.24). To do this,
append the Invoke-Expression cmdlet to the end of the command as shown
in the following example:
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | ConvertTo-HTML | Out-File CL\Data\VMs.htm | InvokeExpression C:\Data\VMs.htm
Figure 5.24
You can write PowerShell data to an HTML report.
As you can see, the process of writing data to an HTML report works pretty
well, but the report is very plain (Figure 5.25) and not very visually appealing.
To make your reports more visually interesting, you can create a style section
and incorporate it into the report.
156
Understanding Hyper-V in Windows Server 2012
Figure 5.25
By default, HTML reports are very bland.
The block of code below (Figure 5.26) creates a PowerShell variable named
$a and then adds an HTML style section to that variable. The actual report is
created as discussed earlier, but with a couple of differences. When it comes
time to issue the ConvertTo-HTML command, you insert the –Head switch
and the $a variable. You also insert the Body tag and a header. The end result
is a much more attractive HTML report (Figure 5.27). This is how the code
is written:
$a = "<style>"
$a = $a + "BODY{background-color:peachpuff;}"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color:
black;border-collapse: collapse;}"
$a = $a + "TH{border-width: 1px;padding: 0px;border-style: solid;bordercolor: black;background-color:thistle}"
$a = $a + "TD{border-width: 1px;padding: 0px;border-style: solid;bordercolor: black;background-color:PaleGoldenrod}"
$a = $a + "</style>"
Get-VM | Select-Object VMName, State, ComputerName, IsClustered,
UpTime, Status | ConvertTo-HTML -head $a -body "<H2>Virtual Machines</
H2>" | Out-File C:\Data\VMs.htm
Figure 5.26
You can add HTML style elements to an HTML report.
157
Understanding Hyper-V in Windows Server 2012
Figure 5.27
HTML reports can be displayed in color.
With a little bit of imagination you can create scripts that produce color-coded
reports. For example, you can list virtual machines that are offline in red and list
online virtual machines in green.
Changing a virtual machine’s state
So far we have discussed PowerShell solely with regard to retrieving
information about a virtual machine or a host server. Although PowerShell
can be a powerful reporting tool, it can also be used to interact with
virtual machines. For example, you can use PowerShell to start or stop
a virtual machine.
There are two cmdlets you can use to change a virtual machine’s state.
These include:
Stop-VM
Start-VM
When you enter the Stop-VM cmdlet, PowerShell will attempt to gracefully shut
down the specified virtual machine. If the virtual machine cannot be brought
down gracefully, you will see a warning message (Figure 5.28) telling you that
the virtual machine cannot be shut down. The message gives you the option
of turning off the virtual machine (without a graceful shutdown) or suspending
the virtual machine.
Figure 5.28
You will see a warning message if a virtual machine cannot be shut down gracefully.
The Start-VM cmdlet starts the virtual machine. The only required parameter is
the name of the virtual machine that you want to start (Figure 5.29).
158
Understanding Hyper-V in Windows Server 2012
Figure 5.29
You can use the Start-VM cmdlet to start a virtual machine.
Creating a virtual machine
You can also use PowerShell to create virtual machines. This involves using
the New-VM cmdlet. At a minimum, you need to specify the name for the new
virtual machine, the virtual machine path and the name of the host on which
the virtual machine will reside. For example, to create a virtual machine named
PowerShellVM in the C:\VMs folder on a host named Lab1 (Figure 5.30), you
would enter the following command:
New-VM –Name “PowerShellVM” –Path “C:\VMs” –ComputerName Lab1
Figure 5.30
You can create virtual machines through PowerShell.
When you enter this command, you will see confirmation that the new virtual
machine was created. The new virtual machine should also be displayed in
the Hyper-V Manager (Figure 5.31).
Figure 5.31
The new virtual machine should appear in the Hyper-V Manager.
159
Understanding Hyper-V in Windows Server 2012
Keep in mind that you will almost always have to make modifications to a newly
created virtual machine before using it. When you create a virtual machine
using the method discussed above, it is allocated minimal hardware that is
almost never suitable for real world use. The hardware allocation includes:
• 512 MB of memory
• DVD drive
• No virtual hard disk
• No network connection
• One virtual processor
Fortunately, you can use PowerShell cmdlets to modify a new or an existing
virtual machine.
Modifying a virtual machine
As you saw in the previous section, you may need to modify a virtual machine
after creating it through PowerShell. Likewise, you may occasionally need
to modify an existing virtual machine’s configuration. For instance, you might
need to add more memory or additional CPU cores to a virtual machine.
This section discusses some techniques for modifying virtual machine
hardware allocation.
Memory
The resource that you will likely have to adjust more often than any other is
memory. You can adjust memory by using the Set-VMMemory cmdlet.
Start the process by entering the Get-VMMemory cmdlet, followed by
the name of the virtual machine (Figure 5.32). This causes PowerShell to display
the virtual machine’s current memory configuration.
Figure 5.32
You can use the Get-VMMemory cmdlet to see a virtual machine’s memory assignment.
The easiest way to reallocate a virtual machine’s memory is to assign a static
amount of memory to the virtual machine by entering the following command:
Set-VMMemory <virtual machine name> –Startup <memory amount>
For example, to add 2 GB of memory to the virtual machine named
PowerShellVM (Figure 5.33), use the following command:
Set-VMMemory PowerShellVM –Startup 2.0GB
160
Understanding Hyper-V in Windows Server 2012
Figure 5.33
You can use the Set-VMMemory cmdlet to allocate memory to a virtual machine.
This command sets the startup memory to 2 GB. You can verify the operation’s
success by using the Get-VMMemory cmdlet.
If you want to configure a virtual machine to use dynamic memory, things
become a bit more complicated. You still use the Set-VMMemory cmdlet,
but you have to include a specification to enable dynamic memory. You will
also have to provide values for the minimum, startup and maximum memory.
You can optionally set a priority and a buffer value for the virtual machine as
well by using the following command:
Set-VMMemory <virtual machine name> -DynamicMemoryEnabled $True
–MinimumBytes <minimum memory> -StartupBytes <startup memory>
-MaximumBytes <maximum memory> -Priority <priority> -Buffer
<buffer value>
For example, suppose you want to configure the virtual machine PowerShellVM
to use a 1 GB of startup memory and you want to set the minimum memory
to 512 MB and the maximum memory to 2 GB. Let’s also assume that you want
to set the priority to 80 and the buffer to 25 (Figure 5.34). You can do this with
the following command:
Set-VMMemory PowerShellVM –DynamicMemoryEnabled $True –
MinimumBytes 512MB -StartupBytes 1GB –MaximumBytes 2GB –Priority 80
–Buffer 25
Figure 5.34
You can also use the Set-VMMemory for configuring dynamic memory.
Now that you know how to allocate memory to a virtual machine, here are
a couple of shortcuts that you can use. Keep in mind that you can use these
shortcuts with any type of hardware allocation. The following example uses
only memory allocation.
161
Understanding Hyper-V in Windows Server 2012
Allocating memory to multiple virtual machines
The first shortcut allows you to allocate memory to multiple virtual machines
simultaneously. The easiest way to accomplish this is to specify multiple virtual
machine names within the Set-VMMemory cmdlet. For example, to allocate
2 GB of memory to virtual machines named NewVM1, NewVM2 and NewVM3
on a server named Lab1 (Figure 5.35), you can use the following command:
Set-VMMemory NewVM1,NewVM2,NewVM3 –Startup 2.0GB
Figure 5.35
You can assign memory to multiple virtual machines.
When the operation has completed, you can verify its success by specifying all
three virtual machine names within the Get-VMMemory cmdlet. For example,
in this situation you would enter:
Get-VMMemory NewVM1,NewVM2,NewVM3
Keep in mind that this is not the only way to allocate memory to multiple
virtual machines. You can also specify the virtual machines to which you want
to allocate memory using filtering. For example, you can create a filter based
on the virtual machine’s name or on the amount of memory that is currently
allocated to the virtual machine.
Pipelining hardware allocations
The other shortcut that is worth knowing is that you can actually allocate
memory to a virtual machine while the virtual machine is being created. This is
done by pipelining the New-VM and the Set-VMMemory cmdlets together.
Suppose, for example, that you want to create a virtual machine named
NewVM4 and allocate 4 GB of RAM to it (Figure 5.36). You can accomplish this
by using the following command:
New-VM –Name “NewVM4” –Path “C:\VMs” –ComputerName Lab1 | SetVMMemory –Startup 4GB
Figure 5.36
You can assign startup memory as a virtual machine is being created.
162
Understanding Hyper-V in Windows Server 2012
Virtual network adapters
Just as you may need to modify a virtual machine’s memory allocation,
you may also need to provision a virtual machine with a virtual NIC. It’s best
to start by viewing a virtual machine’s current virtual network adapter usage.
To do this, enter the Get-VMNetworkAdapter cmdlet, followed by the virtual
machine name (Figure 5.37).
Figure 5.37
You can use the Get-VMNetworkAdapter cmdlet to access virtual network adapter
information for a virtual machine.
In many cases, you may find that although a network adapter has been
assigned to a virtual machine, you must connect that network adapter
to a virtual switch. Fortunately, this is relatively easy to do. While it is possible
to use a single command to attach a virtual network adapter to a virtual
switch, it’s better to use variables because the virtual network adapter name
and the virtual switch name may be long. Using variables reduces the chances
of making a mistake by mistyping one of the names.
Therefore, the first step in the process is to retrieve the name of the virtual
machine’s virtual network adapter and assign this name to a variable named
$VMNic using the following command:
$VMNic = Get-VMNetworkAdapter –VMName <virtual machine name>
The next step is to retrieve the name of the virtual switch by using
the following command:
Get-VMSwitch | Select-Object Name
If you have multiple virtual switches, you can narrow down the results by
specifying the virtual switch’s connectivity. For example, if you only want to use
an external virtual switch, you can use the following cmdlet:
Get-VMSwitch –SwitchType External | Select-Object Name
Now you just need to connect the virtual network adapter to the virtual switch.
You should be able to do this by using the Connect-VMNetworkAdapter
cmdlet; however, PowerShell apparently doesn’t allow you to add the virtual
switch name to a variable and use the variable to connect the virtual switch
to a virtual network adapter. Instead, you have to enter the virtual switch name
in long form. The command looks something like this:
Connect-VMNetworkAdapter –VMNetworkAdapter $VMNic –SwitchName
“<virtual switch name>”
163
Understanding Hyper-V in Windows Server 2012
As a more concrete example, for the virtual switch on a test server named
Intel(R) Gigabit CT Desktop Adapter #2 – Virtual Switch (Figure 5.38), you would
use the following command:
Connect-VMNetworkAdapter –VMNetworkAdapter $VMNic –SwitchName
“Intel(R) Gigabit CT Desktop Adapter #2 – Virtual Switch”
Figure 5.38
You must connect a virtual network adapter to a virtual switch.
Once you have connected the virtual network adapter to the virtual switch,
it is a good idea to verify the connection (Figure 5.39). You can do by entering
the following command:
Get-VMNetworkAdapter –VMName <your virtual machine name> | SelectObject VMName, Name, SwitchName
Figure 5.39
You can use the Get-VMNetworkAdapter cmdlet to verify the connection.
CPU cores
When you create a new virtual machine through PowerShell, Windows
automatically assigns a single virtual processor to the virtual machine. In some
cases, however, a single virtual processor might not be sufficient. Fortunately,
PowerShell makes it possible to add virtual processors to a virtual machine.
Before you attempt to modify a virtual machine’s virtual processor allocation,
it is a good idea to verify the number of virtual processors currently
assigned to the virtual machine (Figure 5.40). You can do this by using
the following command:
Get-VM <virtual machine name>| Select-Object VMName, ProcessorCount
Figure 5.40
It’s a good idea to verify a virtual machine’s current virtual CPU count.
Once you have verified the virtual machine’s current virtual processor
count, you can modify the number of virtual processors that are assigned
to the virtual machine by using the following command:
Set-VMProcessor <virtual machine name> -Count <number of virtual CPUs>
164
Understanding Hyper-V in Windows Server 2012
For example, to assign two virtual processors to a virtual machine named
NewVM1 (Figure 5.41), you can use this command:
Set-VMProcessor NewVM1 –Count 2
Figure 5.41
You can use the Set-VMProcessor cmdlet to configure a virtual machine’s virtual CPU usage.
Of course there are also some other switches that you can use with
the Set‑VMProcessor cmdlet. For instance, if you want to set a reserve,
maximum and relative weight value, you can use a command like this:
Set-VMProcessor <virtual machine name> -Count 2 –Reserve 10 – Maximum
75 – RelativeWeight 200
In case you are not familiar with these particular values, here are their
meanings:
• Limit –The maximum amount of time that a virtual machine is allowed
to use a physical CPU. The default limit is 100% usage.
• Reservation – A percentage of CPU time solely for a specific virtual
machine. By default the reservation is set at 0%.
• Weight – A relative weight that affects how much CPU time a virtual
machine will receive. The default weight is 100.
You can also use the Set-VMProcessor cmdlet to enable compatibility for
older operating systems by including the –Compatibility For Older Operating
Systems Enabled switch in the command, as in the following example:
Set-VMProcessor <virtual machine name>
-CompatibilityForOlderOperatingSystemsEnabled $true
Building a virtual machine from scratch
Earlier in this chapter you saw that it is possible to build a virtual machine
by using the New-VM cmdlet. However, when you use a minimum set of
switches with this cmdlet, the virtual machine is lacking, to say the least.
In fact, the newly created virtual machine doesn’t even have a virtual hard
disk. There are a couple of ways to overcome this problem—the easiest way
being to provision the virtual machine while it is being created. Although this
approach can complicate the New-VM command, it does allow you to create
a fully provisioned virtual machine using a single command.
For example, to create a new virtual machine named NewVM4 that has
a 50-GB virtual hard drive and is located at F:\NewVM4, you could enter
the following command:
New-VM –Name NewVM4 –NewVHDPath F:\NewVM4\disk1.VHDX –
NewVHDSize 50GB –Path F:\NewVM4
165
Understanding Hyper-V in Windows Server 2012
This command (Figure 5.42) works really well for creating a virtual machine
and its virtual hard disk. The problem is that the virtual machine is still a bit
lacking. By default, this virtual machine is only equipped with 512 MB of
memory, a single virtual processor, and the virtual network adapter is not
connected to a virtual switch (Figure 5.43). Never mind the fact that you might
need to create some additional virtual hard disks for the virtual machine.
Figure 5.42
You can create a virtual hard disk and a virtual machine at the same time.
Figure 5.43
By default, a new virtual machine is provisioned with a very modest amount
of hardware resources.
Unfortunately, you can’t do much more with the New-VM cmdlet. You can
specify startup memory, but that’s about it. That being the case, what follows
is a set of line-by-line instructions for creating and provisioning a new
virtual machine.
166
Understanding Hyper-V in Windows Server 2012
This example illustrates how to create a new virtual machine named NewVM5.
The virtual machine will be equipped with two 50-GB virtual hard disks, two
gigabytes of virtual memory, four virtual processors, and it will be connected
to a virtual switch.
Start by creating the virtual machine and its 50-GB boot drive (Figure 5.44),
using the following command:
New-VM –Name NewVM5 –NewVHDPath F:\NewVM5\disk1.VHDX –
NewVHDSize 50GB –Path F:\NewVM5
Figure 5.44
You can create a new virtual machine from the command line.
Now that you have created the virtual machine, you need to provision it. Start
by adding the second 50-GB virtual hard disk (Figure 5.45). You can create
a new hard disk using this command:
New-VHD F:\NewVM5\Disk2.VHDX –Size 50GB
Figure 5.45
You have created a dynamically expanding virtual hard disk.
This command created a 50-GB dynamically expanding virtual hard disk.
The problem is that the virtual hard disk is still not attached to the virtual
machine. You can verify this by entering the Get-VMHardDiskDrive command,
followed by the name of the virtual machine (Figure 5.46).
Figure 5.46
The new virtual hard disk is not attached to the virtual machine.
167
Understanding Hyper-V in Windows Server 2012
This command not only displays the virtual hard disks that are in use, it also
shows which IDE ports are currently in use. When you join the newly created
virtual hard disk to the virtual machine, you will have to choose a set of
ports that are not in use. For example, to use IDE port 0.1 you would use
this command:
Add-VMHardDiskDrive NewVM5 IDE 0 1 –Path F:\NewVM5\Disk2.vhdx
The command does not generate any output, so to verify its success you need
to reissue the Get-VMHardDiskDrive cmdlet (Figure 5.47) as shown below:
Get-VMHardDiskDrive NewVM5
Figure 5.47
You must add the virtual hard disk to the virtual machine.
Now that the virtual hard disks are in place, you simply need to provision
memory, CPU and network connectivity. The task of provisioning memory
and CPU resources to the new virtual machine is easy (Figure 5.48) and can be
accomplished using these commands:
Set-VMMemory NewVM5 –Startup 4GB
Set-VMProcessor NewVM5 –Count 4
Figure 5.48
Adding CPU and memory resources to the virtual machine is easy.
The last step in the process is to connect the virtual network adapter
to the virtual switch. As you may recall, this isn’t a single-step process. You
have to retrieve both the name of the virtual network adapter and the name
of the virtual switch (Figure 5.49). To retrieve the name of the virtual adapter,
use the following command:
$VMNic = Get-VMNetworkAdapter –VMName <virtual machine name>
Next, you need to retrieve the name of the virtual switch. You can do this by
using the following command:
Get-VMSwitch | Select-Object Name
Now you need to connect the virtual network adapter to the virtual switch by
using this command:
Connect-VMNetworkAdapter –VMNetworkAdapter $VMNic –SwitchName
“<virtual switch name>”
You can use the following command to verify connectivity:
Get-VMNetworkAdapter –VMName <your virtual machine name> | SelectObject VMName, Name, SwitchName
168
Understanding Hyper-V in Windows Server 2012
Figure 5.49
Connecting the virtual machine to the network requires a few steps.
The new virtual machine is now fully provisioned. You can verify all of
the virtual machine settings through the Hyper-V Manager (Figure 5.50).
Figure 5.50
You can use the Hyper-V Manager to verify the virtual machine settings.
169
Understanding Hyper-V in Windows Server 2012
Deleting a virtual machine
To delete a virtual machine, use the Remove-VM cmdlet. The only required
parameter is the name of the virtual machine that you want to delete.
Forexample, if you want to delete a virtual machine named NewVM4,
use this command:
Remove-VM NewVM4
When you enter this command, Hyper-V will prompt you for confirmation
(Figure 5.51) before deleting the virtual machine.
Figure 5.51
You can use the Remove-VM cmdlet to delete a virtual machine.
Working with virtual machine snapshots
One of the most frequently used features in Hyper-V is snapshots. Snapshots
allow an administrator to protect a virtual machine prior to performing
a potentially dangerous operation. For example, many administrators are in
the habit of creating a snapshot prior to applying a service pack to a virtual
machine. That way, if the service pack happens to cause problems, the virtual
machine can be easily reverted to a previous state.
Snapshotting through PowerShell can be a bit complex, but the following
examples will give you the basics of how it works. To take a snapshot of
a virtual machine, you can use this command:
Get-VM <virtual machine name> | Checkpoint-VM
For example, to create a snapshot of a virtual machine named NewVM1
(Figure 5.52), you can enter the following command:
Get-VM NewVM1 | Checkpoint-VM
Figure 5.52
The Checkpoint-VM cmdlet is used to create snapshots.
After you have created a snapshot, you probably want to verify that
the snapshot exists. One way of doing this is to select the virtual machine
within the Hyper-V Manager and look at the Snapshots pane (Figure 5.53).
Of course, this chapter is all about PowerShell, so if you want to verify
the snapshot through PowerShell, you can use the Get-VMSnapshot cmdlet
(Figure 5.54) shown below:
Get-VMSnapshot –VMName <Virtual machine name>
170
Understanding Hyper-V in Windows Server 2012
Figure 5.53
The new snapshot is visible through the Hyper-V Manager.
Figure 5.54
You can view snapshots through PowerShell.
Things get a bit trickier if you want to restore a snapshot in order to revert
a virtual machine to a prior state. You can roll back a virtual machine by using
the Restore-VMSnapshot command (Figure 5.55). This command requires you
to provide the name of the virtual machine and the name of the snapshot. You
can enter this information manually, but it is a lot easier to use a command like
this one:
Restore-VMSnapshot –Name (Get-VMSnapshot –VMName “<virtual machine
name>”).Name –VMName “<virtual machine name>”
Figure 5.55
You can use the Restore-VMSnapshot cmdlet to revert a VM to a previous state.
For example, if you want to roll back a virtual machine named NewVM1
to the state in which it existed when the most recent snapshot was created,
you can use this command:
Restore-VMSnapshot –Name (Get-VMSnapshot –VMName “NewVM1”).Name
–VMName “NewVM1”
When you enter this command, PowerShell will prompt you to confirm that you
want to perform the rollback.
171
Understanding Hyper-V in Windows Server 2012
If you decide instead to remove the most recently created virtual machine
snapshot, the command syntax is exactly the same, except that you
would use the Remove-VMSnapshot cmdlet (Figure 5.56) instead of
the Restore‑VMSnapshot cmdlet. The syntax is as follows:
Remove-VMSnapshot –Name (Get-VMSnapshot –VMName “<virtual machine
name>”).Name –VMName “<virtual machine name>”
Figure 5.56
The Remove-VMSnapshot cmdlet is used to delete unwanted snapshots.
It is worth noting that this command does not prompt you for confirmation
before deleting the snapshot. Therefore, you should exercise extreme caution
when using the Remove-VMSnapshot cmdlet.
Live migration of a virtual machine
Live migrations are one of the easier functions to perform through PowerShell.
The PowerShell cmdlet for live migrations is Move-VM. At a minimum
this cmdlet requires you to specify the virtual machine name and the name
of the host server to which the virtual machine will be moved. For example,
to move the virtual machine named NewVM3 to the server Lab2, you use
this command:
Move-VM “NewVM3” Lab2
The problem is that the above command moves the virtual machine itself,
but not the virtual machine’s storage. Therefore, the command is only
appropriate if the virtual machine’s files reside on SMB storage.
In most cases, you need to specify the destination storage path as
an additional switch. To see how this works, imagine that you want to move
the virtual machine NewVM3 to server Lab2 and you want to store the virtual
machine files in F:\VMs (Figure 5.57). You can perform the migration using
this command:
Move-VM “NewVM3” Lab2 –DestinationStoragePath F:\VMs
Figure 5.57
Use the Move-VM cmdlet for live migrations.
172
Understanding Hyper-V in Windows Server 2012
Getting help
Although you can do a lot with regard to managing Hyper-V through
PowerShell, the PowerShell cmdlets and their syntaxes are sometimes
difficult to remember. Fortunately, Microsoft provides a number of different
mechanisms to help you use PowerShell.
The question mark switch
Throughout this chapter you have probably noticed that PowerShell cmdlets
can sometimes use a number of optional switches. Therefore, one of the keys
to using PowerShell effectively is to determine all the options for a particular
cmdlet. This is easier to accomplish than it might seem. To see a list of
the options that can be used with a cmdlet, simply enter the cmdlet followed
by the -? switch (Figure 5.58). For example, to see all of the options for using
the Get-VM cmdlet, enter the following command:
Get-VM -?
Figure 5.58
The question mark switch is used to retrieve the full syntax for any PowerShell cmdlet.
Any time you use the question mark switch, PowerShell asks you if you want
to run the Update-Help cmdlet. The Update-Help cmdlet causes PowerShell
to download the latest help files from the Internet. When the help file update
completes, the full command syntax will be displayed.
Get-Help
PowerShell cmdlets are a combination of nouns and verbs. Sometimes,
however, it can be difficult to remember what noun-verb combinations can be
used together, and this is where the Get-Help cmdlet comes into play. Get-Help
can show you all of the nouns that can be used with a particular verb or all of
the verbs that can be used with a specific noun. For example, in Hyper-V many
of the cmdlets are designed to be used on virtual machines and therefore use
VM as a noun (Get-VM, Set-VM, etc.). If you want to see all of the actions that
can be performed on a VM (Figure 5.59), you can use the following command:
Get-Help *-VM
173
Understanding Hyper-V in Windows Server 2012
Figure 5.59
These are all of the verbs that can be used with the VM noun.
As previously mentioned, Get-Help can be used with both nouns and verbs.
Notice in Figure 5.59 that the last cmdlet on the list is Suspend-VM. If you are
curious as to whether the Suspend verb can be used with nouns other than VM,
you can enter this command:
Get-Help Suspend-*
When you enter this command (Figure 5.60), you will see that PowerShell
uses the Suspend verb for a number of different purposes, some of which are
not even related to Hyper-V. For example, you can use the Suspend verb to
suspend a service or a print job.
Figure 8.60
The Get-Help cmdlet can help you to figure out what noun and verb combinations will
work together.
What-If
As you have no doubt noticed throughout this chapter, some PowerShell
commands are complicated. That being the case, it would be nice to have
a way to make sure that you are entering the correct command before you
actually press Enter. The good news is that Windows gives you a way to
find out what a specific PowerShell command would do before you actually
execute the command. The trick is to append the –WhatIf switch to the end of
the command.
For example, suppose that you weren’t quite sure what would happen if you
executed the New-VM command. You could append the –WhatIf switch to
the command (Figure 5.61) and PowerShell would tell you that the command
would create a new virtual machine named New Virtual Machine.
Figure 5.61
The WhatIf switch is used to find out what will happen if you perform a certain command.
174
Understanding Hyper-V in Windows Server 2012
It is worth noting that not every PowerShell cmdlet can be used with
WhatIf. To see which cmdlets support the use of WhatIf (Figure 5.62), enter
the following command:
Get-Command | Where Definition –Like *whatif*
Figure 5.62
Not every cmdlet works with the WhatIf switch.
IntelliSense
In addition to the PowerShell interface that is shown throughout this chapter,
Microsoft also provides a feature called the PowerShell Integrated Scripting
Environment (ISE). In the Windows Server 2012 version of PowerShell,
the Integrated Scripting Environment contains a feature called IntelliSense,
which anticipates the command that you are about to type and offers help as
you enter the command.
To see how this feature works, go to your Hyper-V server’s Metro interface,
click the Administrative Tools tile and double-click on the Windows PowerShell
ISE command (Figure 5.63), which is found on the Administrative Tools list.
175
Understanding Hyper-V in Windows Server 2012
Figure 5.63
The Windows PowerShell ISE icon is found on the Administrative Tools menu.
When the Windows PowerShell ISE window opens, start typing a PowerShell
command. As you type, the IntelliSense feature will engage and help you with
the command’s syntax (Figure 5.64). For instance, if you type New-V, then
IntelliSense will show you all of the cmdlets that start with New-V. As you
progress through the list of commands, IntelliSense even offers syntax help.
Figure 5.64
Windows PowerShell ISE provides help with command syntax.
The Show-Command pane
The Show-Command pane (Figure 5.65) is another feature of the Windows
PowerShell ISE interface. The Show-Command add-on is displayed on the right
side of the PowerShell ISE window by default, but it can be enabled or disabled
through the interface’s View menu.
176
Understanding Hyper-V in Windows Server 2012
Figure 5.65
The Show-Command pane can help you to assemble PowerShell cmdlets.
As you enter a command, the Show-Command add-on displays various fields
that allow you to enter values to use with the command. For example, if you
were to enter the New-VM command, you could enter values such as the virtual
machine’s name and startup memory.
Once you have filled in the various attribute fields, you can use the buttons
at the bottom of the window to run the command, insert the command into
the PowerShell window or copy the command to the clipboard.
TechNet
Finally, Microsoft TechNet is a great resource for getting help with PowerShell
commands. The page is located at: http://technet.microsoft.com/en-us/library/
hh848559.aspx (Figure 5.66) and contains a full list of every available Hyper-Vrelated cmdlet. Clicking on a cmdlet takes you to a page that provides the full
syntax (Figure 5.67) and some usage examples for the cmdlet.
177
Understanding Hyper-V in Windows Server 2012
Figure 5.66
TechNet provides a reference for all of all of the Hyper-V related cmdlets.
Figure 5.67
Clicking on a link takes you to a page with the cmdlet’s syntax and usage examples.
178
Understanding Hyper-V in Windows Server 2012
About the Author
Brien Posey is a freelance technical writer who has
received Microsoft's MVP award 9 times for his work with
Exchange Server, Windows Server, IIS, and File Systems
Storage.
Brien has written or contributed to about three dozen
books, and has written well over 4,000 technical articles
and white papers for a variety of printed publications
and Web sites.
In addition to his writing, Brien routinely speaks at
IT conferences and is involved in a wide variety of other
technology related projects.
About Veeam Software
Veeam® Software develops innovative solutions for VMware backup, Hyper-V
backup, and virtualization management. Veeam Backup & Replication™ is
the #1 VM Backup solution. Veeam ONE™ is a single solution for real‑time
monitoring, resource optimization, documentation and management reporting
for VMware and Hyper-V. Veeam extends deep VMware monitoring to
Microsoft System Center with Veeam Management Pack™ (MP), and to HP
Operations Manager with Veeam Smart Plug-In™ (SPI). Veeam also provides free
virtualization tools. Learn more by visiting www.veeam.com.
179
Understanding Hyper-V in Windows Server 2012
NEW!
Veeam Backup & Replication™ v6
Extending the lead in VM backup with these new capabilities:
Enterprise scalability: new distributed architecture streamlines deployment
and maintenance of remote office/branch office (ROBO) and large installations.
Advanced replication: accelerates replication by 10x, streamlines failover,
and provides real failback with delta sync.
Multi-hypervisor support: brings Veeam’s award-winning data protection
to Microsoft Hyper-V and lets you protect all your VMs— VMware and Hyper-V—
from one console.
and more!
2010
Products
of the Year
GOLD
To learn more, visit
http://www.veeam.com/backup
180
