Configuring Advanced Windows Server 2012 R2 Services: Virtual Machine and Site Resilience

Lesson 1: Virtual machine movement

Even when you’ve planned its placement well, at some point in a virtual machine’s operational lifespan, you might need to move it from its original Hyper-V host to a new Hyper-V host. If the virtual machine is providing critical services to the network, you need to move the virtual machine in a manner that doesn’t affect the clients that are interacting with it. This lesson describes two technologies that you can use to move virtual machines between Hyper-V nodes. The first involves placing the virtual machine on a Hyper-V failover cluster and accomplishing virtual machine movement by transferring the virtual machine between nodes. The second involves using Shared Nothing Hyper-V Live Migration, a technology new to Windows Server 2012 and improved in Windows Server 2012 R2. The lesson also explains how you can move virtual machines by exporting them and importing them.

Virtual machine failover clustering

One of the most common uses for failover clusters is hosting virtual machines. By deploying a workload, such as SQL Server or Exchange on a highly available virtual machine, you can achieve high availability without the application needing to be aware that it is now highly available. The virtual machine functions normally, providing services to clients on the network, and switches between cluster nodes as necessary in the event that the individual cluster node hosting it requires maintenance or experiences some sort of failure. Building a Hyper-V failover cluster involves first creating a failover cluster and then adding the Hyper-V role to each node of the cluster.

You should use Cluster Shared Volumes (CSVs) to store virtual machines on a Hyper-V cluster. CSVs allow multiple cluster nodes to manage a single shared storage device. This enables you to put multiple virtual machines on the same-shared storage device but have those virtual machines hosted by different nodes in the failover cluster. Cluster Shared Volumes are mapped under the C:\ClusterStorage folder on cluster nodes as shown in Figure 8-1.

When creating a new virtual machine on a failover cluster, you first select which cluster node will host the virtual machine. Figure 8-2 shows the choice between node MEL-HV-1 and MEL-HV-2 when creating a new virtual machine.

When creating a highly available virtual machine, you specify the Cluster Shared Volume path as the location to store the virtual machine, as shown in Figure 8-3. If you have an existing machine that you want to make highly available, you can move the virtual machine to this path. As an alternative, you also have the option of specifying a Server Message Block (SMB) 3.0 file share as the place to store the highly available virtual machine. The selection of a CSV or an SMB 3.0 file share depends on your organization’s storage configuration.

After the virtual machine is created, you can control it using the Failover Cluster Manager console. The move option in the Actions pane enables you to select the cluster node to move the virtual machine to. Figure 8-4 shows a virtual machine named TEST-VM-TWO on the node MEL-HV-2.

In production environments you should ensure that each Hyper-V host has an identical hardware configuration. In development environments this is not always possible. If different processor types are used, for example an Intel processor on one node and an AMD processor on another, you might have to perform a quick migration. Quick migration allows migration between nodes, but there is a disruption in client connectivity. You can allow migration between Hyper-V nodes with different processor types or versions by enabling the processor compatibility setting on the virtual machine, as shown in Figure 8-5.

Shared Nothing Hyper-V live migration

Hyper-V live migration enables you to migrate a virtual machine running on one Hyper-V host to another Hyper-V host without the virtual machine experiencing downtime and without requiring the use of shared storage. You can use Hyper-V live migration to move a virtual machine from one Hyper-V failover cluster to another.

When configuring a computer running Hyper-V to support live migration, you must enable live migrations on the Live Migrations section of the Hyper-V Settings dialog box as shown in Figure 8-6. You must perform this step on both the source and destination Hyper-V servers. When configuring these settings, you must choose an authentication protocol, specify a maximum number of simultaneous live migrations and select which IP addresses can be used for live migration.

When configuring authentication for live migration you can choose between Credential Security Support Provider (CredSSP) or Kerberos authentication. CredSSP requires local sign on to both the source and destination servers to perform migration. Kerberos enables you to trigger live migration from a remote server, but if you choose Kerberos for live migration authentication, you need to configure constrained delegation for the cifs and Microsoft Virtual System Migration Service services on the computer accounts of the computers that host the Hyper-V role. For example, if you want to be able to perform shared nothing live migration between HV-1 and HV-2, you have to configure delegation for HV-2 for these services on HV-1 and configure delegation for these services on HV-2 for HV-1. Figure 8-7 shows the computer account of MEL-HV-1 configured so that the necessary services are delegated for use by MEL-HV-2.

To trigger the shared nothing live migration after you’ve configured the source and destination servers running Hyper-V, right-click the virtual machines that you want to migrate and select Move The Virtual Machine as shown in Figure 8-8. You then specify the address of the remote server and any additional move options, such as whether you want to move all data to a single location on the destination computer or to multiple locations on the destination computer. You can also indicate that you want to move the storage to a shared storage location.

Storage migration

Storage migration enables you to move the virtual machine’s storage from one location to another. This includes the virtual hard disk files, configuration files, checkpoint files, and smart paging files. Checkpoints are the new term for the virtual machine snapshot technology available in prior versions of Hyper-V. During storage migration, you can move all of this data to one location, or you can move it to many locations as shown in Figure 8-9. For example, you might want to move data from one volume to another, from one directory to another, to a shared storage device, or a shared folder hosted on a computer running Windows Server 2012 or Windows Server 2012 R2. You can perform storage migration while the virtual machine is online.

Unlike Hyper-V live migration, which requires you configure the appropriate delegations on the computer accounts, storage migration is simply about moving virtual machine files from one location to another. As long as the storage is accessible to the Hyper-V host, you can use it as a destination during a move operation. For example, in an extreme case, you might attach a temporary universal serial bus (USB 3.0) hard disk drive to a server and move running virtual machines temporarily to this storage device while you modify the configuration of the storage device that normally hosts the virtual machines. When the configuration change is complete, you can then move the virtual machines back to the new storage device without interrupting client access to those virtual machines. To perform storage migration, select Move The Virtual Machine’s Storage as shown in Figure 8-10 when you choose to move the virtual machine.

When you choose to move the storage, you can consolidate the information in one location or move the virtual hard disk files, configuration files, checkpoint files, and smart paging files to separate locations. As Figure 8-11 shows, you can also choose to move only the virtual machine’s hard disk files, keeping the configuration data in its current location.

Virtual machine import and export

When you export a virtual machine, you can choose to export the virtual machine and all its checkpoints, or you can choose to export the virtual machine in the state of a specific checkpoint. When you export a virtual machine with all its checkpoints, the virtual machine is exported with multiple differencing disks that represent the virtual machine in each different checkpoint state. Windows Server 2012 R2 allows you to perform virtual machine export while the virtual machine is running. Windows Server 2012 only allows you to export a virtual machine that is in a shutdown state. When you import a virtual machine that was running at the time of export, the virtual machine is placed in a saved state. You can resume the virtual machine from this state.

When you import a virtual machine, you have three options as shown in Figure 8-12. You can choose Register The Virtual Machine In Place (Use The Existing Unique ID), Restore The Virtual Machine (Use The Existing Unique ID), or Copy The Virtual Machine (Create A New Unique ID). The differences between these are as follows:

• Registering the virtual machine enables you to import the virtual machine into Hyper-V while keeping the virtual machine files in the current location. This method does not generate a new virtual machine ID, so you need to ensure that the originally exported virtual machine is not present on the Hyper-V host that you are performing the import on. You can register a virtual machine in place and then use storage migration to move the virtual machine files at a later point in time.
• Restoring the virtual machine enables you to import the virtual machine into Hyper-V while moving the virtual machine files to a new location. For example, if you export a virtual machine to a removable disk, you import and restore the virtual machine to move the virtual machine off the removable disk to another location. Restoring uses the existing virtual machine ID, which means you need to ensure that the originally exported virtual machine is not present on the Hyper-V host that you are performing the import on.

• Copying the virtual machine enables you to create a separate clone of the virtual machine. All of the virtual machine files are copied to a new location, and you can go and use those source files to reimport the virtual machine again should you need to. When you copy, a new virtual machine ID is created. This allows copies to run alongside each other as each has a separate ID. It’s a good idea to rename virtual machines when you run copies side by side. If you don’t, they retain the original name and you might get confused as to which cloned virtual machine is which.

  

  FIGURE 8-12 Choosing the import type

Lesson summary

• Virtual machines hosted on failover clusters use shared storage to store virtual machine configuration and data files.
• Virtual machines hosted on failover clusters move between cluster nodes using live migration.
• Shared Nothing Hyper-V live migration enables you to move a running virtual machine from one Hyper-V server to another without using shared storage and with no disruption to the virtual machine’s operation.
• Storage migration enables you to move a running virtual machine’s storage to another location that is accessible to the host Hyper-V server.
• You can only export a virtual machine from a Hyper-V server running on the Windows Server 2012 operating system if the virtual machine is shut down.
• When importing a virtual machine, you can import in place using the existing virtual machine ID, import while moving the virtual machine storage, or create a copy of the virtual machine with a new ID. A server cannot host two virtual machines with the same ID.

Lesson review

Answer the following questions to test your knowledge of the information in this lesson. You can find the answers to these questions and explanations of each answer choice in the “Answers” section at the end of this chapter.

1. You have three running virtual machines that are hosted on your Windows Server 2012 R2 Hyper-V server’s C: volume. You want to move these three running virtual machines to another storage location without shutting them down. Assuming enough space is available, which of the following volumes could you use as a destination when performing storage migration? (Choose all that apply.)

   1. File share hosted on a computer running Windows Server 2008 R2
   2. iSCSI connected virtual disk
   3. SSD disk connected through USB 3.0
   4. File Share hosted on a computer running Windows Server 2012 R2

2. You have an existing virtual machine named SYD-DB-VM that is hosted through Hyper-V on a computer running the Windows Server 2012 R2 operating system named SYD-HV-1. You want to create a duplicate SYD-DB-VM named SYD-DB-VM-A and also have it hosted on SYD-HV-1. Which of the following steps should you take to accomplish this goal? (Choose two, each answer forms part of a complete solution.)

   1. Export SYD-DB-VM
   2. Import SYD-DB-VM with the Register The Virtual Machine In-Place option
   3. Import SYD-DB-VM with the Restore The Virtual Machine option
   4. Import SYD-DB-VM with the Copy The Virtual Machine option

3. You arze going to use Kerberos as an authentication protocol for live migration. You are configuring delegation for the computer accounts of the Hyper-V hosts that will host the virtual machines that will participate in the live migration process. Which of the following services must you configure delegation for if you want to support moving virtual machine storage and the virtual machines? (Choose all that apply.)

   1. Dcom
   2. cifs
   3. Hyper-V Replica Service
   4. Microsoft Virtual System Migration Service

4. You are configuring a four-node Hyper-V failover cluster. You want to be able to move running Hyper-V virtual machines between any of the nodes as necessary. Which of the following storage devices should you select when configuring the virtual machines that will be hosted on this cluster? (Choose all that apply.)

   1. Cluster Shared Volume
   2. SMB 2.0 File Share
   3. SMB 3.0 File Share
   4. Distributed File System Share