Modern
Data ProtectionBuilt for Virtualization
A First Look at
Windows Server
2012 R2
and Hyper-V
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 2012.
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 2008. 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.
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 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
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.
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).
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
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.
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
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
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.
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
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.
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
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
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.
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.
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.
All of these capabilities existed in Windows Server 2012. 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.
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.
Workplace join
The Active Directory domain model has remained largely unchanged since the days of Windows 2000. Although Microsoft has made enhancements to the Active Directory over the last thirteen years or so, the basic concept of joining computers to the domain still works basically the same way that it did over a decade ago.
Although the concept of domain joining PCs has long been an effective way of verifying a PC’s identity, the technology simply has not aged well. Today, PC use
is rapidly declining and many users prefer instead to use consumer electronic devices to access corporate resources. One of the problems with using such devices is that they cannot be domain joined in the traditional way.
That being the case, one of the most important changes in Windows Server 2012 R2 is that of a workplace join. Workplace join can be thought of as a next-generation Active Directory join. The difference being that workplace joins
are specifically intended for use with consumer devices that would not normally
be able to be enrolled in the Active Directory. Another major difference is that workplace joins are designed to be self-service. This allows users to enroll their own devices into the Active Directory.
Workplace join capabilities are facilitated by a new feature known as the Device Registration Service. The Device Registration Service is a subcomponent of the Active Directory Federation role found in Windows Server 2012 R2. When a user attempts to join a consumer device to the Active Directory, the Device
Registration Service will take the appropriate steps to confirm the user’s
identity to make sure that they are authorized to enroll a device, and will then
provision the device with a certificate that is used going forward to establish
the device identity and to facilitate single sign-on capabilities.
The benefit to allowing consumer devices to be domain joined is that doing
so gives administrators a way of positively identifying the devices and to grant or deny access based on device type. If at a later time a user decides to leave the company (or upgrade to a new device) they can disjoin the device from the Active Directory. Doing so will remove all corporate resources from the device without impacting the user’s personal data and app collection the way that a normal remote wipe would.
At the time that Windows Server 2012 R2 is released, workplace joins will be supported for Windows 8.1 devices (including Windows RT-based devices) and for iOS devices. Microsoft has indicated that support for other types of consumer devices will be added in the near future.
Multi-tenant VPN gateway
As you have probably noticed, Windows Server 2012 R2 is geared heavily toward multi-tenant environments, either in public clouds or in the enterprise. One of the ways that Microsoft is facilitating multi-tenancy is through improved network virtualization. Virtual networking in Hyper-V decouples virtual subnets from the physical network. Doing so allows virtual networks to be constructed without regard to the underlying network infrastructure. The end result is that a single host may have many different virtual networks which must all coexist,
while continuing to isolate traffic from one another.
Of course it is unrealistic to assume that these virtual networks will remain completely isolated from the rest of the world. Most virtual networks will require internet connectivity. This is where the Windows Server Gateway comes into play. The Windows Server Gateway is a software-based router that
is designed to route traffic between the internet (or other physical network) and a specific virtual network. In other words, the Windows Server Gateway acts as something of a multi‑tenant VPN by allowing clients to connect to their
own virtual network without exposing the contents of that virtual network (or even its existence) to other tenants who have virtual networks on the same physical hardware.
Conclusion
As you can see, Windows Server 2012 R2 offers a number of significant
improvements. In addition to those discussed in this article, there are also
hundreds of minor improvements and new features. You can access the full
About the Author
Brien Posey is a freelance technical writer who has received
Microsoft's MVP award nine times for his work with Exchange
Server, Windows Server, IIS, and File Systems Storage.
Brien has written or contributed to about three dozen books, and has written well over 4,000 technical articles and white papers for a variety of printed publications and Web sites. In addition to his writing, Brien routinely speaks at
IT conferences and is involved in a wide variety of other technology related projects.
About Veeam Software
Veeam® is Modern Data Protection™. We believe today’s IT requirements
have changed and that “3C” legacy backup problems—high costs, increased complexity and missing capabilities—are no longer acceptable for any organization. Veeam provides powerful, easy-to-use and affordable solutions
that are Built for Virtualization™ and the cloud—a perfect fit for the modern
datacenter.
Veeam Backup & Replication™ is VMware backup, Hyper-V backup, recovery
and replication. This #1 VM Backup™ solution helps organizations meet RPOs
and RTOs, save time, eliminate risks and dramatically reduce capital and operational costs. Veeam Backup Management Suite™ combines Veeam Backup
& Replication and Veeam ONE™ in a single integrated solution to protect
virtualization investments, increase administrator productivity and help mitigate daily management risks. Veeam Management Pack™ (MP) extends enterprise
monitoring to VMware through Microsoft System Center. Veeam also provides
free tools for the virtualization community. Learn more by visiting http://www.veeam.com.
