Windows Server 2012 Hyper-V: Deploying Hyper-V Enterprise Server Virtualization Platform: Get to grips with Windows Server 2012 Hyper-V the easy way. This comprehensive tutorial takes you through every step of planning, designing, and implementing Hyper V with clear instructions and screenshots. The only guide you need.

As we have been seeing over a decade, computer technology is getting micro—with great enhancements for computer processing power and increased memory and storage capacity. These new changes are allowing new computers to process more data in less time, with less overhead. One of the great examples of these new enhancements is the inclusion of multiple cores in a physical processor, where a single processor chip socket virtually holds multiple processors, and thus we can have more processor cycles and more physical RAM in a single box.

These highly intelligent and fast beasts can handle an immense amount of workload, so running a single application role that might not be a resource-hungry application may result in the hardware box being underutilized. This is not a single commodity loss, because it might also make your other investments underutilized, and that would also result in bad return on investment (ROI). This is a situation where the customer is not making the most of his/her investment.

Virtualization allows a server administrator to consolidate server workloads in the form of virtual machines. This allows an organization to fully utilize its servers with multiple operating systems running on the same box.

On one side, server consolidation gives the benefit of utilizing hardware resources to their utmost capacity, and on the other side it also helps to reduce the power consumption and keeps the datacenter environment less occupied with issues of cooling and loaded racks. Imagine a system's infrastructure without virtualization and server consolidation concepts: where for each single application frontend tier, we have to keep a physical server in the rack; where combining power, cooling, and rack space management would result in high maintenance costs from all aspects of datacenter management. Thanks to virtualization technology, which helps to reduce the maintenance cost by consolidating these multiple applications boxes and running them on a single physical box as virtual machines, we produce more with less cost and overhead while equally using our underutilized resources across the infrastructure.

Physical-to-virtual, also known as P2V, is one of the most demanding features of any server consolidation and datacenter consolidation project, where client requirements are to convert the running physical boxes regardless of the operating system or installed applications, and convert them into VMs. There is also the opposite possibility, virtual-to-physical (V2P), but it hardly comes as a requirement to a hypervisor administrator.

P2V allows legacy application servers to be converted into virtual machines and run on newer hardware, which is one of the features of server consolidation. This helps an organization to get rid of the legacy hardware, which consumes space in the racks, generates a huge amount of heat, and most importantly consumes a lot of power. So you can imagine removing these physical application boxes and converting them into a virtual machine, which can save a lot of your money and datacenter resources. On one end, P2V benefits from server consolidation concepts, and on the other side it provides a flexible platform for migrated servers and applications, by allowing dynamic memory and flexibility to add additional processors and hard disk drives, which is very difficult to do if you run a physical server.

Okay, we talked about P2V, but what about virtual-to-virtual (V2V)? This is also a growing requirement, especially with the availability of native Windows Server hypervisor (Hyper-V), and its fast growth and high demand. Nowadays, most of the customers that are running their Microsoft platform want to migrate their virtual workloads from a third-party hypervisor to Microsoft Hyper-V. This move gives them a lot of flexibility and saves costs, and since the release of Windows Server 2012, where Hyper-V 3.0 provides a number of features and functionalities that no other third-party hypervisor product provides within the industry, many of them have this requirement of converting third-party virtual machines into Hyper-V virtual machines.

Microsoft has made this conversion easier for its customers by providing a handy way of converting these third-party virtual machines into Hyper-V virtual machines using Microsoft Virtual Machine Converter. For example, this allows Hyper-V customers to convert VMware virtual machines into Hyper-V virtual machines. Microsoft Virtual Machine Converter is a part of the Microsoft Solution Accelerator suite, which can be downloaded and used from the Microsoft Solution Accelerator website (http://technet.microsoft.com/en-us/library/hh967435.aspx).

This is one is my favorites, where Hyper-V gives you immense flexibility in building R&D and testing environments with the luxury of many features that help you to test different product applications on different operating systems. Hyper-V admins can also script the creation of virtual machines based on their test cases, which expedites the process of building the R&D environment. We all know that during the testing phase, especially for developers, sometimes it is necessary to reformat the operating system. Hyper-V gives you the snapshot facility, where a Hyper-V administrator can take a snapshot of a VM at any given time and restore it later at any stage of the test cycle, which will take the virtual machine to the exact same state as when the snapshot was initially created. Running multiple OSs with a limited amount of physical RAM has always been a bottleneck, and therefore to provide a handy way to administrators to deal with such cases, Hyper-V provides the virtual machine state saving feature, where you can save or resume the virtual machine to the same state, and at the same time continue with other testing activities.

Business continuity or business continuity planning (BCP) allows an organization to survive major catastrophic situations, and makes sure that business continuity and operation will not be affected if the primary facility is unavailable. Hyper-V provides sound business continuity support for an organization whose mission-critical application is running in a virtualized mode. Microsoft Windows Server 2012 Hyper-V provides BCP capabilities for virtualized workloads by allowing them to replicate to a disaster recovery site, where a primary site Hyper-V server can as act as primary server and a Hyper-V server sitting in the disaster recovery site can get all the VM-related replication from its primary instance.

Hyper-V also allows customers to configure VSS backups for the virtual machines, where VSS writers for Hyper-V virtual machines make it possible for VSS-based software solutions to take virtual machine backups while the virtual machine is up and running.

So let's say you are taking your Hyper-V VM's backup, and unfortunately your entire primary datacenter goes down. In this case, you can get your off-site backup tape drives and restore the virtual machine to any point in time on the same or a different host. We will be covering Hyper-V backup and recovery concept in details in Chapter 10, Performing Hyper-V Backup and Recovery.

The other feature that Hyper-V supports for the BCP concept is VM migration. Hyper-V provides two flavors of VM migration, quick migration and live migration. In quick migration, which came into existence with the first release of Hyper-V Windows Server 2008, a Windows failover cluster is configured with shared cluster storage, on which the virtual hard disks (VHDs) are stored. So, if a failure occurs and one Hyper-V host node goes offline, the cluster senses and moves the VM's workload to another Hyper-V host. In quick migration, while the migration happens, the virtual machine's state (more importantly, the storage VM state) is paused till the time the failover of other resources occurs. Once all the resources get up and running for the second running cluster node, the virtual machine gets resumed on this node. Since quick migration was a cluster failover based migration feature, it introduced some delay in a few user-centric applications.

The other migration solution provided to Hyper-V was live migration, which had come with Windows Server 2008 R2. Live migration was more mature than quick migration, and, as it sounds, it was a live migration of VM workload from one Hyper-V node to another. Live migration of virtual machines provides great flexibility for planned migration, where an administrator, while patching the physical Hyper-V hosts, can migrate a guest virtual machine to other available Hyper-V hosts without any disruption in the machine's availability on the network. While performing the migration, the Hyper-V server creates a secure session from the source Hyper-V host to the destination Hyper-V host where the virtual guest machine is intended to be migrated, as part of the migration plan. During the live migration process, the source Hyper-V server starts copying the memory pages to the destination Hyper-V server, and once all of the memory pages are copied to the destination Hyper-V server, the VM moves and starts on the secondary Hyper-V node. This process is network resource intensive, where the memory pages get copied to the destination Hyper-V server over the network. And for this reason, it would be advisable to have a dedicated NIC card for the live migration process. We will go deeper into the Hyper-V migration strategies in the coming chapters, so stay tuned.

It is quite cloudy here today! In the beginning of the book, we gave an introduction about cloud computing after introducing virtualization. In the cloud services delivery model, the service provider provides computing capabilities, also called a pool of resources, such as network, servers, storage, and applications. These services are highly elastic and flexible with the users' needs. Let's see how a hypervisor works hand in hand with cloud computing. Hyper-V as a hypervisor provides the base virtualization layer of cloud computing, on which the cloud computing builds its underlying infrastructure and provides computing resources. Hyper-V as a base hypervisor in cloud computing solution delivery works with Microsoft System Center 2012 product suite, and covers end-to-end cloud delivery, where the Microsoft System Center 2012 product provides self-service portal, cloud service request, orchestration, operations monitoring, and virtual workload management as well.

Hypervisor is a term used to describe the software stack, or sometimes operating system feature, that allows us to create virtual machines by utilizing the same physical server's resources. Based on the hypervisor type, some hypervisors run on the operating system layer, and some go underneath the operating system and directly interact with the hardware resources, such as processor, RAM, and NIC. We will understand these different types of hypervisors shortly—in the coming topics.

Hypervisor is not a new term that rose with VMware or Microsoft. If you see the history of this term, it takes you back to the year 1965, when IBM first upgraded the code for its 360 mainframe system's computing platform to support memory virtualization. By evolving this technique, they provided great enhancements to computing as a technology, by addressing different architectural limitations of mainframes.

Now let's discuss the various available hypervisor types, which may be categorized as shown next.

Type 1 (bare metal) hypervisors

Type 1, or bare metal, hypervisors run on the server hardware. They get more control over the host hardware, thus providing better performance and security. And guest virtual machines run on top of the hypervisor layer. There are a couple of hypervisors available on the market that belong to this hypervisor family, for example, Microsoft Hyper-V, VMware vSphere ESXi Server, and Citrix XenServer.

Type 2 (hosted) hypervisors

These second type of hypervisors run on top of the operating system as an application installed on the server. And that's why they are often referred to as hosted hypervisors. In type 2 hypervisor environments, the guest virtual machines run on top of the hypervisor layer.

The preceding diagrams illustrate the difference between type 1 and type 2 hypervisors, where you can see that in the type 1 hypervisor architecture, the hypervisor is the first layer right after the base hardware. This allows the hypervisor to have more control and better access to the hardware resources.

While looking at the type 2 hypervisor architecture, we can see that the hypervisor is installed on top of the operating system layer, which doesn't allow the hypervisor to directly access the hardware. This inability to have direct access to the host's hardware increases overhead for the hypervisor, and thus the resources that you may run on the type 1 hypervisor are more while those on the type 2 hypervisor are less for the same hardware.

The second major disadvantage of type 2 hypervisors is that this hypervisor runs as a Windows NT service; so if this service is killed, the virtualization platform will not be available anymore. The examples of Type 2 hypervisor are Microsoft Virtual Server, Virtual PC, and VMware Player/VMware Workstation.

Monolithic hypervisors

The monolithic hypervisor is a subtype of the type 1 hypervisors. This type of hypervisor holds hypervisor-aware device drivers for guest-operating systems. There are some benefits of using monolithic hypervisors, but there are also a couple of disadvantages in using them. The benefit of using monolithic hypervisors is that they don't need a parent or controlling operating system, and thus they have direct control over the server hardware.

The first disadvantage of using monolithic hypervisors is that not every single hardware vendor may have device drivers ready for these types of hypervisors. This is because there are number of different motherboards and other devices. Therefore, to find a compatible hardware vendor who supports specific monolithic hypervisors could be a potentially hard task to do, before choosing the right hardware for your hypervisor. The same thing can also be counted as an advantage, because each of these drivers for the monolithic hypervisors are tested and verified by the hypervisor manufacturer.

The second disadvantage of a monolithic hypervisor is that it allows the hypervisor to get closer access to kernel (Ring 1) and hardware resources, which may open the door for the malicious activities taking advantage of this excessive privilege. The openness to this threat goes against the trusted computing base (TCB) concept. VMware vSphere ESXi Server is an example of this type of bare metal hypervisor.

Microkernel hypervisors

In this type of hypervisor, you have device drivers in the kernel mode (Ring 0), and also in the user mode (Ring 3) of the trusted computing base (OS). Along with this, only the CPU and memory scheduling happens in Ring 1.

The advantage of this type of hypervisor is that since the majority of hardware manufactures provide compatible device drivers for operating systems, with the microkernel hypervisor, finding compatible hardware is not a problem.

A microkernel hypervisor requires device drivers to be installed for the physical hardware devices in the operating system, which is running under the parent partition of a hypervisor. This means that we don't need to install the device drivers for each guest operating system running as a child partition, because when these guest operating systems need to access physical hardware resources on the host computer, they simply do this by communicating through the parent partition. One of the features of using microkernel-based hypervisors is that these hypervisors don't hurt the concept of TCB; thus, they work within the limited, privileged boundaries. The hardware-assisted virtualization Hyper-V that Microsoft implemented is an example of a microkernel-based hypervisor.

Tip

What is a trusted computing base?

You can find information about TCB at http://csrc.nist.gov/publications/history/dod85.pdf.

Now let's take a look at the Hyper-V architecture diagram, as follows:

As you can see in the preceding diagram, Hyper-V behaves as a type 1 hypervisor, which runs on top of hardware. Running on top of the hypervisor are one parent partition and one or more child partitions. A partition is simply a unit of isolation within the hypervisor that is allocated physical memory address space and virtual processors. Now let's discuss the parent and child partitions.

Virtual devices (vDevices) are the application interfaces that provide control over devices to the VMs. There are two types of vDevices, as follows:

Let's see the difference between these devices.

The earlier versions of Windows Server, such as Windows Server 2008 / 2008 R2, allowed administrators to automate various tasks with respect to managing Hyper-V environments using WMI and a portion of Windows PowerShell. But the problem with WMI is that it is designed for developers, and for a server administrator it was a bit difficult to work with. On the other side, PowerShell didn't provide end-to-end automation and support for Hyper-V and virtual machine management related features.

In Windows Server 2012, Microsoft provided full support, through Windows PowerShell, for automation of Hyper-V as the hypervisor and VM-related management tasks. Windows Server 2012 includes 164 built-in PowerShell cmdlets for administrators to work with and customize as per their needs.

Initially, the Dynamic Memory feature was introduced in Windows Server 2008 R2 SP1, which changed the way Hyper-V virtual machines were assigned virtual memory. And it also gave great flexibility to administrators to dynamically manage the physical server memory between the various virtual workloads in the datacenter.

With the dynamic memory improvements introduced in Windows Server 2012 Hyper-V version 3.0, you can now attain a higher level of consolidation with improved reliability for virtual machine restart operations. There are two main areas of dynamic memory that are improved in Hyper-V version 3.0.

The first one is the availability of the minimum memory feature. Before version 3.0 of Hyper-V, however, only the startup memory setting and maximum memory limit settings were available. Here, the unavailability of the minimum memory limit requires administrators to set the startup memory at a higher level because most of the server-side applications require more memory to be available. Once the virtual machine reaches the stable state and loads all its operations, this higher amount of memory, which is now accessed according to the needs of the virtual machine, stays idle with no utilization.

The problem of giving extra amount of memory to the virtual machine to supply required amount of RAM for the boot processes was addressed by Windows Server 2012 Hyper-V version 3.0, and with the ability to set the minimum RAM to a lower value we can have a separate startup RAM that could be higher. This new feature helped to save the extra memory from staying idle in the virtual machines.

The second major improvement that happened around the dynamic memory concept is second-level paging, which is a cure for problems such as memory shortage. Second-level paging provides an alternate for the memory on a disk, which can be used in case there is no available memory available to give a virtual machine its configured and required startup amount of RAM.

Windows Server 2008 / 2008 R2 fulfilled virtual machine network isolation related requirements with the VLAN concept, but there were a series of problems associated with this solution because there were a number of limitations that made it difficult to provide true isolation between different machines in the cloud and dynamic datacenters. These limitations were as follows:

In addition to the preceding limitations, there were a series of drawbacks of using VLANs for VM isolation requirements, which are as follows:

Windows Server 2012 addressed all these problems, and provided a true virtualized network isolation for virtual workload. Customers who are running Hyper-V in dynamic and cloud-based environments can even use overlapping IP addressing schemes between different VMs. It's a big topic, so we will discuss that in detail in the coming chapters.

In the earlier version of Hyper-V Windows Server 2008 / 2008 R2, the method of copying data requires data to be read from and written to different locations, which can be a time-consuming process. Windows Server 2012 introduced a new way to tackle this problem by supporting offloading data transfer operations so that these operations can be passed from the guest operating system to the host hardware. This ensures that the workload can use storage enabled for offloaded data transfer, as it would if it were running in a nonvirtualized environment. The Hyper-V storage stack also issues offloaded data transfer operations during maintenance operations for virtual hard disks, such as merging disks and storage migration meta operations where large amounts of data are moved.

This gets me excited, as this feature makes Hyper-V so different and unique from other hypervisors available on the market. This is a brand-new feature; it came with Hyper-V version 3.0. This allows the Hyper-V administrator to set a virtual machine to be replicated to another Windows Server 2012 Hyper-V instance regardless of its location and IP subnet. This feature also supports business continuity and disaster-recovery solutions to critical virtual workloads in virtualized environments.

In the early days of Hyper-V Windows Server 2008 / 2008 R2, organizations had to implement chargeback mechanisms for Hyper-V virtual workloads using either a third-party or a self-developed solution, which would never be cheap or handy.

With Windows Server 2012, Microsoft introduced native functionalities in Hyper-V for chargeback calculation with historical information. This feature is called Hyper-V resource metering.

With the recent improvements around the storage area, disks are now being shipped with the capabilities to read/write on disk sectors from 512-byte sectors to 4096-byte sectors (also known as 4 KB sectors). This feature enhances disk storage density and reliability. Earlier editions of Hyper-V and Windows Server didn't provide compatibility for this new enhancement, especially in the case of VHD drivers that assume a physical sector size of 512 bytes and issue 512-byte I/Os, which made them incompatible with these disks.

As a result, the current VHD driver cannot open VHD files on physical 4-KB sector disks. Hyper-V makes it possible to store VHDs on 4-KB disks by implementing a software Read-Modify-Write (RMW) algorithm in the VHD layer to convert the 512-byte access and update request to the VHD file to corresponding with 4-KB accesses and updates.

This is one of the coolest features, and one of my favorites. In the earlier versions of Hyper-V, if you wanted to provide a storage area network (SAN) or logical unit number (LUN) to a virtual machine, the only method available was to use iSCSI SAN or connect the LUN to the Hyper-V host using Fibre Channel or iSCSI, and from there take the LUN inside the VM using a pass-through disk. But this solution doesn't allow us to assign a LUN directly to the VM, therefore not leveraging the benefits from the Fibre Channel investment that was made.

Hyper-V Windows Server 2012 addressed this problem, and provided a new feature, where an administrator can take advantage of its Fiber Channel SAN, and directly connect the SAN fabric to a virtual machine. You can configure as many as four virtual Fiber Channel adapters on a virtual machine and associate each one with a virtual SAN. Each virtual Fiber Channel adapter connects with one World Wide Name (WWN) address or two WWN addresses to support live migration. You can set each WWN address automatically or manually.

In Windows Server 2008 R2 the maximum size of a VHD was 2 TB, but this size was not enough for mission-critical or media-related applications, which store huge amounts of data on a frequent basis. Windows Server 2012 solved this problem by introducing a new virtual hard disk format, VHDX for virtual machines; VHDX has a maximum permissible size of 64 TB.

Before the release of Windows Server 2012, in the early operating system version, administrators used to install third-party software for NIC teaming, which was only supported in the physical servers. Most of the time, these third-party NIC teaming and NIC management suites caused compatibility problems with the other installed Microsoft application on the servers, and were difficult to manage.

Windows Server 2012 addressed this problem, and provided a native feature in the operating system to set up the team for the NICs, which is not only supported for the physical boxes but also provides out-of-the-box support for the guest operating systems. This new feature provides both NIC failover and link aggregation (combining the bandwidths) of the NICs.

The Hyper-V infrastructure based on Windows Server 2008 / 2008 R2 had limitations and issues with regards to Hyper-V vSwitch. Customers who were running virtual workloads in tenants and wanted to isolate their virtual machines' communications faced problems such as difficulty in performing QoS and network troubleshooting. Windows Server 2012 Hyper-V addressed all these problems, and came up with a series of new enhancements that catered to all of these requirements. Windows Server 2012 Hyper-V includes an extensible virtual switch feature, which is a layer-two virtual network switch and acts as a bridge between the virtual machine and the physical core network. This extensible virtual switch can also be used in enforcing policies for network-level security, network isolation, and multitenancy support.

This enhanced virtual network switch supports Network Device Interface Specification (NDIS) filter drivers and Windows Filtering Platform (WFP) callout drivers. This enhanced version of Hyper-V virtual network switch also provides the capabilities for non-Microsoft vendors to build and integrate APIs for rich-level integration with Hyper-V virtual network switches.

Hyper-V gained a lot of confidence from its customers after the first release in 2008. And with Dynamic Memory and CSV-based live migration, Hyper-V became a critical component in datacenters, and hypervisor administrators also started treating Hyper-V as a production virtual workload instead of keeping it only for testing virtual machines. But there were some caveats in Hyper-V Windows Server 2008 / 2008 R2 with regards to scaling up the virtual workloads, especially for virtual machines that require extensive amounts of processing and memory. These critical applications are usually online transaction processing (OLTP) databases and online transaction analysis (OLTA) applications. For another instance, you can take SQL Server as the best example of these resource-hungry applications, which requires a large number of processors and a large amount of RAM. For these types of applications, Hyper-V was failing because of the limits introduced: a maximum of four virtual processors and up to 64 GB of memory.

As a major feature of Windows Server 2012 Hyper-V, it provides support for up to 320 logical processors, and up to 4 TB or more of memory. This series of enhancements made Hyper-V significant in the market as a hypervisor among all other competitors.

Windows Server 2008 R2 provided a handy way of migrating virtual machines from one Hyper-V host to another, while the virtual machine storage stayed in the same place. This feature helped administrators to migrate workloads in a planned migration window. But when it came to storage migration, no solution was available, except that we shut down the virtual machine and manually copy and paste the virtual machine storage to the target location.

Windows Server 2012 Hyper-V version 3.0 addressed these problems with the improved Microsoft Cluster Service (MSCS), where Windows Server 2012 supports a clustered virtual machine storage running on a clustered Hyper-V node, and can be migrated from one location to another while the virtual machine is up and running. This feature doesn't stop or save the virtual machine while the users are accessing the virtual machine.

Before the release of Windows Server 2012 Hyper-V version 3.0, virtual machine storage was not supported on a network share (SMB), which was the most awaited feature of Hyper-V. With the release of Windows Server 2012, Microsoft made this available, and now customers can use SMB file sharing for hosting their virtual machine storage files.

We will learn more about this in the coming chapters. So stay tuned.

The difference between the earlier Microsoft virtualization products and Hyper-V is mainly the processor requirements: where the earlier Microsoft virtualization products, such as Virtual PC and Virtual Server, could run on the 32-bit operating system, Hyper-V only works with 64-bit compatible processor hardware. Along with the 64-bit processor available, there are two other elements that are required by Hyper-V in order for the processor to operate; they are as follows:

We can summarize the processor requirements as follows:

All those storage designs that are supported and workable with Microsoft Windows Server for a particular operating system version are applicable for Hyper-V. But there is a catch—since usage of disk storage changes when it comes to Hyper-V, there are some recommendations that you should consider before you plan and buy hardware for your Hyper-V server.

There will be multiple concurrent sessions on the storage—where a number of virtual machines' virtual storage (VHD, VHDX) will be located—so disk storage with fewer disk spindles will provide poor disk I/O, which will eventually cause poor virtual machine performance. So it is always recommended to use storage with more disk spindles for Hyper-V, which provides better disk I/O, and thus better virtual machine performance.

Let me elaborate this: having more disk spindles means that on your storage side, either your local server storage or SAN storage, you would have more than one disk, and based on your performance and failover requirements you might want to choose an appropriate RAID model for this. So, in this type of setup, more disks would be added to your storage pool and the disk I/O for read/write would be spread across all these disks, which will provide a better resiliency and performance.

The following table shows the list of Microsoft Windows Server operating systems and their versions that can run Hyper-V:

The following are the memory requirements for the Hyper-V host and guest machines:

Installing Microsoft Hyper-V requires 10 GB of disk space on the Server.

We will now discuss the two major factors that may require sizing of disk storage with respect to paging file requirements.

All the following listed server operating systems are supported to be virtualized on Windows Server 2012:

All the following client operating systems are compatible and supported to be virtualized on Windows Server 2012 Hyper-V: