A First Look at Windows Server 2012 R2 and Hyper-V

Transcription

1 A First Look at Windows Server 2012 R2 and Hyper-V Brien M. Posey Modern Data Protection Built for Virtualization

2 Although Windows Server has long been a solid server platform, it has lagged far behind competing products in areas such as virtualization. When Microsoft created Windows Server 2012, one of their key design objectives was to create a hypervisor that was on par with offerings from VMware. Although Microsoft has largely achieved (and in some areas even surpassed) this goal, there was still room for improvement. The soon-to-be released Windows Server 2012 R2 is designed to further improve upon Windows Server Server virtualization In Windows Server 2012, Microsoft did more work on Hyper-V than any other area of the operating system. It should therefore come as no surprise that Windows Server 2012 R2 is also heavily focused on server virtualization. Generation 2 virtual machines Even though Hyper-V has become more feature-rich over the years, the virtual machines (VMs) themselves have adhered to the same basic format ever since their introduction in Windows Server That being the case, Microsoft has decided to modernize VMs in Windows Server 2012 R2. To do so, they have introduced the concept of generation 2 VMs. Before I explain what generation 2 VMs are, I want to point out that first generation VMs are still fully supported. You can migrate your existing VMs to Windows Server 2012 R2 with Hyper-V or you can create new VMs using either a first-generation or a second-generation structure. In order to understand the concept behind second-generation VMs, you have to understand that every previous version of Windows was designed to operate on physical hardware. That being the case, Hyper-V VMs emulated certain physical hardware devices that were considered to be universal standards. Although this approach has worked well historically, hardware emulation tends to be slower than direct hardware access. More importantly, some of the emulated devices simply do not exist on modern servers. Second-generation VMs are designed to be used with modern server hardware, and do not rely on emulation. The end result is more efficient hardware usage, faster VM boot times, and much faster guest operating system installations. Of course these benefits come at a price. Specifically, the operating system that is running on the VM must be capable of supporting the devices that are exposed through the virtualized environment. The only operating systems that Microsoft supports for use within a second-generation VM are 64-bit editions of Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. 2

3 It is also worth noting that once a VM has been created, there is no way to change its generation. For example, you cannot upgrade a first generation VM to a second-generation VM. Likewise, you cannot downgrade a second generation VM to a first-generation VM. Being that second-generation VMs do not support emulated hardware, you might be curious as to what types of hardware devices are actually exposed through the Device Manager. You can see a comparison in the two figures shown below. Figure A shows the Device Manager from a guest operating system running on a first-generation VM. Figure B shows the Device Manager in a second-generation VM. Figure A. This is the Device Manager on a first-generation VM. 3

4 Figure B. This is the Device Manager on a second-generation VM. Second-generation VMs offer advantages beyond performance. For starters, second-generation VM support Secure Boot. In fact, Secure Boot is enabled by default. Another advantage is that it is now possible to boot from a SCSI virtual hard disk. In fact, IDE Virtual Hard Disks (VHDs) are not even supported in second generation VMs. Incidentally, this also means that the ability to boot a VM from a physical SATA DVD drive has been removed. If you need to boot a VM from a DVD, you will have to create a SCSI virtual DVD drive. Some of the other notable changes in second-generation VMs include UEFI firmware support and the ability to perform a PXE boot from a standard network adapter. Extended replication capabilities I have never made any secret of the fact that I think that the replication feature was the single best addition to Windows Server 2012 with Hyper-V. In case you are not familiar with this feature, it allows you to replicate a VM (or more precisely a collection of VHDs) from one host server to another. The replication feature isn t as robust as failover clustering, but you can use it to perform planned or unplanned failovers to a replica VM. The replica isn t kept in lockstep with the primary VM copy, but in most cases the replicate is within five minutes of being current. 4

5 As you can imagine, the replication feature is a great solution for organizations that lack the budget or the technical know-how to implement a full-blown failover clustering solution. Unfortunately however, the replication feature is somewhat limited, even beyond the lack of real-time failover capabilities. The main two limitations inherent in the replication feature are the fact that you can only establish a single replication target and the fact that replication occurs according to a schedule that is set by the operating system, not by the administrator. Both of these issues have been addressed in Windows Server 2012 R2 with Hyper-V. The most important change that Microsoft has made to the replica feature is the ability to replicate a VM to two separate host servers. By doing so it becomes possible to have an on-premises replica and an off-premises replica. That way, organizations can have a copy of the VMs that reside on site, but also have a secondary copy stored securely off site, either in a secondary datacenter or in the cloud. Some might be quick to point out that this type of replication requires three separate Hyper-V servers, and that if you have three Hyper-V servers you could just as easily create a failover cluster. While this may be true, a three node failover cluster is not suitable for spanning across multiple datacenters, whereas a three node replica is. Choosing between a failover cluster and a three-way replica is really a matter of deciding what type of protection your VMs need. A three node cluster can provide instant failover for VMs. In contrast, the replication feature allows for manual failover (both planned and unplanned) and allows you to store a copy of your data safely off site. The best solution for protecting your VMs, of course, is to create a multi-site cluster, but doing so requires additional cluster nodes. Multi-site clusters must also adhere to certain infrastructure requirements pertaining to things like latency and domain membership. The other major change that Microsoft has made to the replication feature is the ability to schedule the replication process. As previously mentioned, Windows Server 2012 with Hyper-V had a fixed replication schedule of five minutes. You couldn t complete the replication any more quickly or any more slowly. In Windows Server 2012 R2 with Hyper-V it is possible to adjust the replication schedule. You can replicate a VM s contents as frequently as every thirty seconds or as infrequently as every fifteen minutes. It s obvious why more frequent replications could be advantageous. After all, the more frequently a VM is replicated the less chance of data loss occurring should the primary copy become damaged. However, you may be wondering why anyone would want to slow the replication process down so that a VM is replicated less frequently. 5

6 The reason for less frequent replication has to do with Hyper-V s perception of a replication failure. If a replication failure occurs then the replication process stops. The administrator must correct the problem that caused the replication failure and then manually reinitiate the replication process. A replication failure is triggered when twelve replication cycles have been missed back-to-back. If you are replicating your VMs every thirty seconds, then a replication failure could occur after six minutes of lost connectivity. This might not be a big deal for organizations with reliable connectivity, but if you are replicating across slow or unreliable links, six minute gaps in connectivity are more likely. In those types of situations you could adjust the replication frequency to occur every fifteen minutes. That way, it would take a full three hours of lost connectivity to trigger a replication failure. Live migration performance options Live migrations refer to the ability to move a running VM from one Hyper-V host server to another. Microsoft did a lot of work around live migrations in Windows Server 2012 with Hyper-V. Among the new features were the ability to perform simultaneous live migrations and the ability to live migrate a VM to a host server regardless of whether or not it existed within the same cluster as the host server on which the VM was currently running. In Windows Server 2012 R2 with Hyper-V, Microsoft has introduced some performance options for live migration. Previously live migration occurred over a standard TCP/IP connection. This option still exists in Windows Server 2012 R2 with Hyper-V, but is not selected by default. The default option is to use compression for live migration. This option compresses the contents of the VM s memory prior to transmitting it to the host server to which the VM is being live migrated. Doing so allows the live migration process to occur much more quickly. The actual performance gain that you can expect to see varies considerably based on the amount of memory that a VM is using. In addition to the compression option, Microsoft also offers an SMB option. Rather than compressing the VM s memory, the memory contents are transmitted over an SMB connection. This option requires both Hyper-V hosts to have network adapters that support Remote Direct Memory Access (RDMA). You can see the live migration performance options in Figure C. 6

7 Figure C. Windows Server 2012 R2 with Hyper-V offers various performance options for live migrations. Exporting and cloning capabilities Hyper-V administrators have long had the ability to export a VM. Doing so provides a rudimentary method for cloning VMs. The process isn t as easy or as seamless as what is available through some backup applications, but it works. In the past, the biggest limitation to exporting and cloning Hyper-V VMs was that the VM had to be powered off at the time of the export. In Windows Server 2012 R2 this limitation has been removed. You can now export a VM even if it is running. On the surface, this enhancement to Hyper-V might seem trivial. However, there are a number of situations in which having the ability to export a VM while it is running could prove to be very useful. For example, if you want to clone a production VM for use in a lab environment, then you don t want to have to take that production machine offline just to accommodate the cloning process. Once again, however, there are backup applications that will allow you to create virtual lab environments based on your production environments on the fly without having to go through an export or clone process. 7

8 Having the ability to export a running VM may also come in handy for migration testing. For instance, if you were considering migrating a VM to a hosted cloud service, you could use the export function to clone the VM and test the migration process without having to take your production VM offline to do so. Although you can export a VM through the Hyper-V Manager, as shown in Figure D, there are two PowerShell cmdlets that can also be used. The Export- VM cmdlet is used to export a VM. Similarly, the Export-VM Snapshot cmdlet is used to export a VM based on a previously created snapshot. Figure D. Hyper-V allows you to export a VM while it is running. Copy files to a running VM Another new capability is the ability to copy files to a running VM. In the previous version of Hyper-V, an administrator who needed to write files to a VM had a couple of different options. One option was to create a file share within a VM and then use that file share to copy files across the network to the VM. Another option was to shut down the VM, mount the VHD, and then copy data to it. This was generally the method that had to be used if an administrator needed to make a big change to the contents of a VHD. 8

9 In Windows Server 2012 R2, Microsoft has given us the ability to copy files to arunning VM without using a network connection. In order to enable this ability, the Integration Services must be installed on the VM and a specific integration service called the Guest Services must be enabled. The Guest Services are not enabled by default. You can enable the Guest Services through the Hyper-V Manager as shown in Figure E, or you can use a PowerShell cmdlet called Enable-VMIntegratonService. Figure E. The Guest Services must be enabled if you want to copy files to a running VM without using a network connection. Running the Guest Services enables the copy process, but you will still need a mechanism for copying files to the VM. This mechanism is a new PowerShell cmdlet called Copy-VMFile. Virtual Hard Disk resizing In Windows Server 2012, Microsoft introduced a new VHDX-based virtual hard disk format. The VHDX format overcame many of the limitations associated with the legacy VHD format. In Windows Server 2012 R2, Microsoft has added the ability to resize a VHDX-based virtual hard disk even if the VM is running. By doing this, you can increase the size of, or shrink, the VHD. There are two things to keep in mind with regard to resizing the VHD on a running VM. First, this feature is only supported for VHDX files and the VHD must be attached to the VM by a virtual SCSI controller. 9

10 Second, resizing a VHD has a similar effect to installing a new hard disk on a physical server. In other words, resizing a VHD changes the its raw capacity. It does not however, change the size of the volumes that reside on it. That isn t to say that you can t resize a volume, but doing so is a separate operation. Depending upon the volume structure, you might even have to delete a volume s contents in order to resize the volume. Storage Quality of Service If the term Quality of Service (QoS) looks familiar, it s probably because QoS has been around in one form or another for well over a decade. QoS typically refers to a networking standard that can be used to limit bandwidth consumption or to reserve bandwidth for a particular application. Windows Server 2012 R2 with Hyper-V introduces a new form of QoS called Storage QoS. If you stop and think about it for a moment, the basic premise behind server virtualization is that all of the VMs that are running on a particular host server share a finite pool of physical hardware resources. The key to making server virtualization works is to ensure that none of the VMs consume physical resources to the degree that they begin to starve other VMs. Historically, Hyper-V has made it easy to limit resource consumption for things like CPU usage or memory usage. Even disk capacity usage is relatively easy to control. However, there hasn t been a good way to natively control disk I/O consumption. This is where the new Storage QoS feature comes into play. As you can see in Figure F, Storage QoS allows you to limit disk I/O consumption for individual virtual hard disks. Doing so is a great way to prevent VMs that are running I/O intensive applications from choking out neighboring VMs. 10

11 Figure F. The Storage QoS feature allows you to limit the disk I/O for a VHD. Dynamic Memory support Dynamic Memory refers to Hyper-V s ability to allocate and deallocate physical memory for a VM on an as-needed basis. The idea is that by providing a VM with exactly the amount of physical memory that it requires (no more, no less), it becomes possible to maximize the VM density for a particular host because physical memory is being used as efficiently as possible. Although Hyper-V has long supported the use of Dynamic Memory, only Windows operating systems were supported. Windows Server 2012 R2 with Hyper-V adds Dynamic Memory support for VMs that are running Linux operating systems. On a side note, Microsoft has also made some changes to Windows Server Backup that allow it to back up VMs that are running Linux. Of course Windows Server Backup is a very low-end backup solution that is not suitable for use in most production environments. 11

12 Shared Virtual Hard Disks The shared VHDs feature in Windows Server 2012 R2 with Hyper-V seems to be one of the most misunderstood features of the new operating system. The name implies that the feature somehow allows you to share a VHD among multiple VMs. Although this idea holds true in a sense, the feature is actually oriented towards guest clustering. As you probably know, Windows Server has long allowed for the creation of failover clusters. The idea behind doing so is that a supported application can be clustered so that if the underlying server were to fail, the application can instantly be moved to an alternate cluster node where the application can continue running uninterrupted. Failover clustering was originally intended for use on physical servers. Today however, organizations are rapidly converting their physical servers to virtual servers. In doing so, many organizations have gone so far as to convert physical cluster nodes into VMs, thereby creating guest clusters. A guest cluster is a failover clustering environment that exists solely on virtualized hardware. Microsoft does support the use of guest clusters, even with the previous version of Hyper-V. As might be expected, however, there is a laundry list of requirements that must be met in order for a guest cluster to be supported. One of the big requirements was previously that guest cluster nodes (VMs that are acting as cluster nodes) must be connected to shared storage by way of an iscsi connection or a Fibre Channel connection. This is where the shared VHD feature comes into play. Rather than requiring guest cluster nodes to establish connectivity to shared storage by way of iscsi or Fibre Channel, the guest cluster can make use of commodity storage in the form of a shared VHDX file. In order to do so, the VHDX file must be stored on a cluster shared volume. The use of a shared virtual hard disk does not impact the live migration process so long as any hosts to which the VM could potentially be migrated have the ability to retain connectivity to the shared VHD file. However, storage live migration (the ability to move VM storage while the VM is running) is impacted. If you want to perform storage live migration of a shared VHD, you must take one of the guest cluster nodes offline. The Hyper-V Virtual Switch In Windows Server 2012 R2, Microsoft has done quite a bit of work with regard to the Hyper-V Virtual Switch. Microsoft has improved virtual switch performance through the use of receive side scaling. This technology distributes the network processing load across multiple CPU cores so as to allow a higher overall throughput to be achieved. 12

13 Microsoft has also sought to improve performance through the dynamic load balancing of network traffic. Windows Server 2012 introduced software level NIC teaming, but did not perform any sort of load distribution across the NICs within the team. This has changed in Windows Server 2012 R2, where a dynamic load balancing mechanism moves traffic streams from NIC to NIC within the NIC team in order to achieve the highest possible throughput. Microsoft is also now allowing port ACLs to be configured at the virtual switch. This is great news for those who operate multi-tenant environments because it means that network security policies do not have to be managed at the VM level. Failover clustering enhancements When it comes to failover clustering in Windows Server 2012 R2, it is the new shared virtual hard disk feature that has been getting all of the attention. Even so, Microsoft has been quietly making a number of other improvements to failover clustering. Most of these improvements are minor, but useful. For example, Microsoft has improved the cluster node health detection mechanism and they have implemented an automatic VM drain on shut down feature that allows VMs to be automatically live migrated when a cluster node is shut down. Perhaps the most underrated improvement to failover clustering is the automatic tie breaker. Failover clusters are based on a majority node set model. This means that in order for the cluster to retain quorum (and remain functional) the majority of the cluster nodes must be online and accessible. Microsoft defines the majority as half plus one. For instance in a four node cluster, three nodes would be required to remain functional for the cluster to retain quorum. This model works well for on premise clusters, but it doesn t work so well for multi-site clusters. In a WAN link failure were to occur then each site is under the impression that all of the nodes in the other site are offline. If neither site contains the majority of the cluster nodes (and all of those nodes are functioning), the cluster will lose quorum. This problem is a bit of a catch-22, because placing the majority of the nodes into either site eliminates the possibility of a site level failover. The only viable solution thus far has been to put an equal number of nodes into each site and then use a tie breaker node (or a witness server) at a third site to make site level failovers possible. 13

14 In Windows Server 2012 R2, Microsoft has added a new tie breaker feature. Now instead of a third site being required, you can define a site that should take priority in the event of a 50/50 split, such as would occur in the event of a WAN failure. Enhanced session mode For administrators in SMB-class organizations, the new enhanced session mode might be one of the most welcome improvements to Hyper-V. If you are in the habit of managing Hyper-V through the Hyper-V Manager, then you know that your ability to interact with a VM is somewhat limited. Previously when you use the Hyper-V Manager to connect to a VM, keyboard and mouse inputs were sent to the VM and screen refreshes were sent back to the console. Beyond that your only options for interacting with the VM through the Hyper-V Manager were some limited file copy capabilities. If you needed to interact with a VM in a manner that was more similar to that of interacting with a physical server, then your best option was to establish a Remote Desktop Services session directly to the VM rather than using the Hyper-V Manager. Doing so generally provided a better experience, but it meant that the administrator had to take the time to enable remote administration of the VM, and it also meant that the VM had to be connected to an externally accessible virtual network. In Windows Server 2012 R2 with Hyper-V, Microsoft has provided an enhanced session mode that is more like what you would normally get if you connected directly to a VM using the Remote Desktop Services. Specifically, this means that there are a number of local resources that can be redirected when using the VM connection. Some of these resources include audio, printers, the clipboard, USB devices, smart cards, drives and even some supported plug and-play devices. Unfortunately, the enhanced session mode is not supported for use by every guest operating system. For the time being it will only be supported on Windows Server 2012 R2 and Windows 8.1. Not only does Microsoft allow for the redirection of certain devices, but there is also a new VM Direct Connect feature. In short, the VM Direct Connect feature allows administrators to establish a Remote Desktop connection to any running VM over the VM bus. While this might not initially sound like anything new, the connectivity method is implemented in such a way that an administrator can establish a connection even if the VM does not have an IP address that would normally be reachable. 14

15 Automatic VM activation Another very welcome improvement in Windows Server 2012 R2 with Hyper-V is automatic VM activation. Windows Server 2012 R2 Datacenter Edition is licensed to allow an unlimited number of Windows Server 2012 R2 VMs on each licensed host. Microsoft makes it possible to do so without having to manually manage guest machine product keys or activate VMs. Automatic VM activation requires the host server to be running Windows Server 2012 R2 Datacenter Edition. The guest operating systems that are supported for automatic activation include Windows Server 2012 R2 Datacenter, Standard and Essentials. To enable automatic activation, you must properly license and activate the host. After doing so, there is a simple command that must be run from an elevated command prompt. This command copies the Automatic VM Activation (AVMA) key to the VM and completes the activation. The command is: SLMGR /IPK <AVMA_Keys> As an alternative, the AVMA keys can also be added to an unattended setup file. The automatic activation feature is more than just a time saver. It is extremely useful in environments where there is no internet connectivity available. Previously, such environments required VMs to be activated by phone, which took several minutes for each VM. Cross-version live migration One of the major limitations that has always been inherent in Hyper-V is that if you wanted to use the live migration feature, then all migration targets had to be running the same version of the hypervisor. Microsoft is loosening this restriction with the release of Windows Server 2012 R2. For the first time ever, cross-version live migrations will be possible. Servers that are currently running Windows Server 2012 will be able to live migrate VMs to Windows Server 2012 R2 servers. This is the only form of cross-version live migration that will be possible. You will not be able to live migrate from Windows Server 2012 R2 to Windows Server 2012 or to any other legacy version of Windows. 15

16 Even though the cross-version live migration feature is unidirectional, it is still tremendously beneficial. The reason for this is that the cross-version live migration feature makes upgrading to Windows Server 2012 R2 relatively painless. Rather than having to go through extensive planning and a manual migration, organizations will be able to deploy Windows Server 2012 R2 computers at their leisure, and then simply live migrate their existing VMs to the new platform. Deduplication of running VMs With Windows Server 2012 R2, Microsoft is finally supporting deduplication for running VMs. Doing so has a couple of interesting benefits. First of all, deduplication can decrease the storage consumption for VMs. Most organizations try to achieve a degree of consistency across all of their VMs. For example, they might try to use a common guest operating system wherever possible or a common set of patches. This means that there tends to be a high degree of redundancy in virtual server environments, and much of this redundancy can be removed through deduplication. This tends to be especially true for VDI environments which may have hundreds of copies of identical virtual desktops. The end result is a significant storage space savings. More importantly, however, reducing the required storage footprint may mean that an organization is able to take advantage of higher-performance storage that would have been cost prohibitive had the data not been be deduplicated. For example, the VM storage footprint might be reduced to the point that the use of solid-state storage becomes affordable. Another benefit to deduplicating running VMs is that only a single copy of each storage block is stored. The side effect of this is that commonly used storage blocks can be cached, either to solid-state storage or to memory. This caching of frequently used storage blocks can result in a tremendous improvement in performance. 16

17 Non-virtualization-related features Although Microsoft has placed a very heavy emphasis on server virtualization in Windows Server 2012 R2, there are also a number of new or enhanced features that are not directly related to server virtualization. While these might not be classified as Hyper-V features, many impact the virtualization infrastructure in some way. Work folders Desktop versions of Windows have long had the ability to synchronize content for offline viewing. This allows users to work on various files while disconnected from a corporate network, and then have their changes automatically synchronized the next time that they connect. This ability still exists in Windows Server 2012 R2 and in Windows 8.1, but has been modernized. The file and folder synchronization capabilities and Windows Server 2012 R2 and Windows 8.1 are known as work folders. Work folders are designed to allow users to synchronize content across a variety of different devices. This in itself is new because previous versions of Windows generally assumed that the user would only be synchronizing content to a single device. More importantly however, work folders are tied into native Windows Server file services. This means that a file server can act as a centralized synchronization point, and can therefore take advantage of features such as failover clustering, which allows the feature to be made highly available. Furthermore, backend file server features help to prevent data leakage due to security breaches. For example, if a user were to compose a file on their laptop and then synchronize that file with the file server, Windows Server can be configured to analyze the contents of the file and classify the file accordingly. If the file is found to contain sensitive information, IRM policies can be applied to the file before re-synchronizing them back out to the endpoint devices. Desired State Configuration One of the big problems that large-scale environments have always faced is that of configuration drift. Such organizations usually use templates to ensure that VMs are initially configured according to the corporate security policies. Over time, however, configurations are often altered (perhaps in response to fixing some sort of problem). These configuration changes are what s known as configuration drift. Windows Server 2012 R2 provides a tool through PowerShell that can help to reduce the chances of configuration drift occurring. This new tool is called the Desired State Configuration (DSC) tool. 17

18 Because DSC tool is PowerShell based, it is going to take a little bit of getting used to, and there is quite a bit of work that has to occur up front in order to receive any benefit from the tool. The tool works by allowing an administrator to create a PowerShell file that defines the appropriate configuration for a particular class of server. For example, an administrator might be able to define the roles and features that should (and should not) be present on a file server. In addition there are other configuration details that can be defined, such as custom registry settings. Once the configuration file has been created, it can be used to create a MOF file, which can then be used to configure VMs. Where things really get interesting, however, is when you begin to look at the administrator s ability to configure both push and pull configurations. In other words, the PowerShell scripts can be used to help provision brand new machines. At the same time, however, it is also possible to have machines periodically check the configuration file, compare it to their own configuration, and then remediate any differences. This should go a long way toward helping to eliminate configuration drift. What might be even more beneficial, however, is that the DSC tool can be used to provide a centralized way of making wide scale changes. If for example an administrator decides to make a configuration change to all of the web servers in an organization, they would not have to change every machine manually. Instead, the PowerShell file could be updated to incorporate the change and then the individual machines created later check in, see the change, and apply that change. Storage tiering Windows Server 2012 introduced a number of improvements to storage. Perhaps the most notable of these improvements was the introduction of Windows storage pools. In case you are not familiar with Windows storage pools, they are a mechanism for abstracting physical storage. Storage pools are really nothing more than a collection of physical disks. VHDs can be created on top of the storage pool and used by the operating system. The New Virtual Hard Disk Wizard even allows for the creation of mirrored or parity storage within the storage pool. 18

19 All of these capabilities existed in Windows Server Windows Server 2012 R2 adds the concept of storage tiers. If you look at Figure G, you can see that Windows Server 2012 R2 differentiates between mechanical storage and solid-state storage within the storage pool. When a VHD is created, it can be tiered in a way that allows the most frequently used storage blocks to be cached on solid-state storage while mechanical storage is used for everything else. The actual caching process is completely dynamic and happens behind the scenes. Figure G. Windows Server 2012 R2 differentiates between mechanical storage and solid state storage. 19

20 As you can see in Figure I, storage tiers can be enabled on a per-vhd basis. Furthermore, administrators can control the size of the high-speed storage tier, so as to avoid exhausting the server s available solid-state storage. Figure I. Storage tiers are defined on a per virtual hard disk basis. Storage pinning One aspect of tiered storage that has not received a lot of attention is the ability to pin a file directly to the high-speed storage tier. This is beneficial if there are certain files to get used on a frequent basis. Suppose for instance that you were using tiered storage for VDI. VDI environments sometimes make use of a master VM image, and a number of differencing disks. You could place the master VM image directly onto the fast storage tier, and then place the individual differencing disks on a slower tier. Write-back cache Tiered storage can also be used to implement a form of write-back caching. Normally, Hyper-V does not support caching data that needs to be written to disk. All write operations are processed immediately rather than being cached to memory. However, Windows Server 2012 R2 makes it possible to cache write operations to solid-state storage. Solid-state storage is generally unsuitable for use as a primary data repository due to its limited size and high cost. However, it works really well as a cache because it does deliver a much higher IOPS rate than conventional storage does. Using solid-state storage as a write-back cache can greatly improve performance for Hyper-V. 20