Hands-on Guide:
Understanding
Hyper-V
in Windows Server 2012
Contents
Chapter 1. An Introduction to Hyper-V 3.0 3
Chapter 2. Failover Clustering 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
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
Chapter 1
An Introduction
to Hyper-V 3.0
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.
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
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.
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).
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
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).
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
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
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.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. Move 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).
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).
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
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).
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).
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 full-server 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.
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.
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.
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).
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).
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
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).
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.
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.
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).
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).
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.
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.
Chapter 2
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
The maximum number of virtual machines per host that can be powered on at any given time
384 1024
Maximum number of virtual machines in
a cluster 1000 4000 Maximum number of
hosts per cluster 16 63 Maximum RAM per
host server 1 TB 2 TB
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.
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.
• 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.
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.
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
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).
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.
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.
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
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).
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
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.
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
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
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
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).
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
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.
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
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
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. Go 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
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.
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
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).
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.
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).
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
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.
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).
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.
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.
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.
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).
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).
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).
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).
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).
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.
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).
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
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
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).
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.
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
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
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.
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.
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
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.
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
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.
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
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.
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.
Chapter 3
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.
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).
