Hyper-V

Hands-on Guide:

Understanding Hyper-V in Windows Server 2012

Brien PoseyPete Zerger, Chris Henley

2Understanding Hyper-V in Windows Server 2012

ContentsChapter 1. An Introduction to Hyper-V 3.0 3Chapter 2. Failover Clustering 30Chapter 3. Migrations 84Chapter 4. Managing Virtual Machine Failover 123Chapter 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-Vdeployment 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 flavorsBefore 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 requirementsAccording 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 servers 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 its 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 servers 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 servers BIOS.

Installing Windows Server 2012 and Hyper-V 3.0Setting 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.


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 Microsofts 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. Accept the license agreement and click Next (Figure 1.5).

Figure 1.5

You must accept Microsofts 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

The installation process will now begin.

Deploying Hyper-V 3.0After 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).


Figure 1.9

Choose the Add Roles and Features command.

3. When the Add Roles and Features Wizard launches, click Next to bypass the wizards 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).

10


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.

11


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 tasksAfter the installation process completes, you may need to perform a number of post-deployment tasks, which might include:

Configure the hosts IP address

Rename the host

Join the host to a domain

The sections that follow will walk you through performing each of these tasks.

12


Configure the hosts IP addressIn 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 servers 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.

13


Figure 1.15

Provision your management NIC with a static IP address and click OK.

Rename the hostWindows 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).

14


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.

15


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.

16


Join the host to a domainThe 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.0If 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).

17


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).

18


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.

Figure 1.23

Choose the edition of Windows Server 2012 that you want to install.

19


7. Click Next.

8. When prompted, accept the license agreement and click Next (Figure 1.24).

Figure 1.24

You must accept Microsofts 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.

20


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.0One 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 machinesThe 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).

21


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).

22


Figure 1.29

You can monitor the export process through the Hyper-V Manager.

Importing virtual machinesImporting 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 wizards Welcome screen.

4. Click the Browse button.

23


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.

24


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).

25


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.

26


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 machines 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.0a process that is not entirely intuitive.

Microsofts 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

27


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. Dont 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 shouldnt 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).

28


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.

29


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.

30


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

Failover Clustering

31


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.

32


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 planningBefore 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, youll need to take into account a number of other considerations, including:

Domain membership Domain membership isnt 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.

33


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 nodes 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 storageAs 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.

34


Installing the failover clustering featureThe 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.

35


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 ClusterNow 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.

36


Figure 2.4

Click on the Create Cluster link.

4. Click Next to bypass the wizards 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.

37


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.


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.

38


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.

39


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 roleThe 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 wizards 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.

40


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).

41


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.

42


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 tolerantSo 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, its 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 | | Roles (Figure 2.13).

Figure 2.13

Navigate through the Failover Cluster Manager to Failover Cluster Manager | | 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 wizards 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).

43


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.

44


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 Managers 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.

45


Building a failover cluster using shared storageEven though you can build a Hyper-V 3.0 cluster without the need for shared storage, Microsofts 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 featureThe 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.

46


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 ClusterNow 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.


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.


5. Specify the names of the servers that you want to include in the cluster (Figure 2.19).

47


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.

48



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.

49


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.

50


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 storageIn 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.

51


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 servers 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 servers physical disks.

52


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.


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.

53


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.

54


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.

55


Using Windows Storage SpacesAs 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 poolThe 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:


2. Click on the File and Storage Services option, found in the console tree.

3. Click on Disks to verify that all of the servers 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).

56


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 wizards 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.

57


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.

58


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.


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).

59


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.

60


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).

61


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 wizards 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).

62


Figure 2.42

Verify that the virtual disk has been created successfully.

Building an iSCSI targetAs 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 InitiatorBefore 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 nodes IQN when you configure the iSCSI target. To start each nodes 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 sheets Configuration tab and note the Initiator Name (Figure 2.43).

5. Repeat these steps for each cluster node.

63


Figure 2.43

Note the IQN for each cluster node.

Installing the iSCSI target softwareAlthough 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.


3. When the Add Roles and Features Wizard launches, click Next to bypass the wizards Welcome screen.

4. On the Select Installation Type screen, choose the Role-Based or Feature-Based Installation option (Figure 2.44).

64


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.

65


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).

66


Figure 2.47

Click Install to install the iSCSI Target software.

15. When the installation completes, click Close.

Configuring the iSCSI targetNow 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.


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.

67


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).

68


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.

69


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.

70


Attaching the cluster nodes to the iSCSI storageNow 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.

71


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).

72


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 wont 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.

73


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.

74


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.



10. When the Failover Cluster Manager opens, navigate through the console tree to Failover Cluster Manager | | Storage | Disks (Figure 2.59).

Figure 2.59

Navigate through the Failover Cluster Manager to Failover Cluster Manager | | 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.

75


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 roleThe 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.


3. When the Add Roles and Features wizard launches, click Next to bypass the wizards Welcome screen.

76


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).

77


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 tolerantNow 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.

78


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\. 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.

79


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 | | Roles (Figure 2.66).

Figure 2.66

Navigate through the Failover Cluster Manager to Failover Cluster Manager | | Roles.

80


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 wizards 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).

81


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.

82


After the virtual machines become fault tolerant, you should see them listed in the Failover Cluster Managers 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.

83


Figure 2.71

The Hyper-V Manager lists the virtual machines as being clustered.

Using SMB storageThis 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.

84


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 Migrations

85


Testing failover clusteringOne 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 dont 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 clusterAlthough 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 clusters 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:



3. When the Failover Cluster Manager opens, navigate through the console tree to Failover Cluster Manager | | 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.

86


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).

87


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 migrationsHyper-V doesnt 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).

88


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.

89


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 mismatchIf 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).

90


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.

91


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 machines performance because the feature works by disabling the virtual machines access to some of the more advanced CPU features such as Misaligned SSE or POPCNT.

Live migrations beyond the clusterOne 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.

92


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 machines 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 Machines Data to a Single Location This option places all of the virtual machine components into a single location.

Move the Virtual Machines 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:


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 | | 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).

93


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).

94


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 wizards Welcome screen.

12. Choose the Move the Virtual Machine option and click Next (Figure 3.13).

95


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.

96


14. Click Next.

15. Choose the option to Move the Virtual Machines 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 machines components. It is usually acceptable to choose the option to Move the Virtual Machines 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.

97


Figure 3.16

It is usually acceptable to move the virtual machines 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.

98


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.

99


6. Click Next.

7. Choose the Move the Virtual Machines 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\ (Figure 3.20).

100


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\\ as the destination location folder (Figure 3.21).

Figure 3.21

Enter the path in which the virtual machine will be stored.

101


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 wizards 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).

102


Figure 3.23

Verify that the virtual machine is running in its new location.



21. Navigate through the Failover Cluster Manager to Failover Cluster Manager | | 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).

103

Understanding Hyper-V in W

Documents

Hyper-V