How-To
Hyper-V Deep Dive 6: Security and Disaster Recovery
We've looked at quite a bit so far in regards to the newest version of Microsoft Hyper-V: the huge changes to networking functionality, scalability enhancements, NUMA management, cluster patching and VM monitoring.
Let's now turn to security and disaster recovery mprovements, particularly with Bitlocker Drive Encryption and Hyper-V Replica.
More on this topic:
The second best way to make sure that nefarious hands don't get hold of your VHDX/VM files is by encrypting the drives where they are stored. The best way is to use good physical security for your datacenter.
Using BDE on servers that come with a Trusted Platform Module (TPM) chip to encrypt the drives that store the VMs comes with a very small (1-2%) performance overhead, while giving you peace of mind that the disks will be unreadable if they're removed. The management of TPM chips has been improved in Windows 8 and Server 2012, making for much smoother configuration. Be aware that you can't use BDE within VMs, only on the disks where their VHDXs are stored. Shared SAN volumes formatted with Cluster Shared Volumes (CSV) 2.0 can now be protected with Bitlocker.
Other security recommendations for Hyper-V remain the same as in earlier versions: Use Server Core (much easier now that the GUI can be installed, used to initially configure the server and then removed) or Hyper-V server if you don't need VM licensing and only run management and backup agents on the host; have a separate NIC for management, use administrator segregation to ensure that host administrators don't have access to VMs and vice versa and consider using IPSec (with appropriate hardware support in your NICs) for your networks. Microsoft's own internal test labs mandate the use of IPSec and thus Live Migration and other Hyper-V features have been extensively tested with it.
Account management for Hyper-V administrators in large environments can be a bit cumbersome as they often had to be local administrators on each individual hosts. Windows Server 2012 adds a new local security group, Hyper-V Administrators, which gives members full access to all features of Hyper-V without granting them full local administrator access.
 |
Figure 1. Configuring HVR is very straightforward. (Click image to view larger version.) |
This addition to the arsenal of new features is definitely the most exciting for small and medium business, putting DR functionality within reach of their budget that they've never had access to before.
Hyper-V Replica provides asynchronous replication of a VM from one host to another, doesn't require shared storage or any special hardware and each end of the replication relationship can either be a stand-alone host or a cluster. The hosts don't need to be in the same domain, nor do they need to be domain joined and the VMs that are replicated can be any OS that's supported by Hyper-V. Replication can take place over ordinary ADSL or other slow connections, depending on the amount of data that change in each VM and how many VMs you are replicating.
Likely scenarios where HVR will be adopted are branch office VMs that are protected by being replicated back to head office, and small businesses whose IT service provider offers the additional service of protecting their VMs.
To implement HVR you need to determine if the primary and replication host are in the same network/domain or if a firewall separates them. For same or trusted domain hosts you can use Kerberos authentication which leaves the replication traffic unencrypted. For all other scenarios you need to implement certificates for authentication and traffic encryption. You can exclude particular VHD/VHDX files from replication and also select if you want additional replication points. By default only the "latest" copy of the VM is kept, you can select to keep additional hourly recovery points that lets you roll back a VM in time (for instance after a malware infection). Replication lag is between 5 and 15 minutes, depending on the time required for each replication operation.
 |
Figure 2. Configuring additional replication points to be saved offers you some flexibility in being able to "roll back" a VM to a previous point in time. (Click image to view larger version.) |
Note that HVR is a single replication relations ship from one host to another, you can't chain multiple hosts together for the same VM, although a host can be both a primary and a replica host for different VMs and different VMs can be replicated to from one hosts to different hosts as your scenario requires.
If either end is going to be part of a Hyper-V cluster, the Hyper-V Replica Broker role needs to be enabled for the cluster. If you're running applications with transaction logs you can optionally enable application consistent recovery points which will use VSS to quiesce the application before replication, ensuring that the application in the replicated VM will start successfully.
The initial replication can take place over the network if sufficient bandwidth is available, either immediately or at a later scheduled time or you can create a backup to external media and then ship it to the replica site. If you already have a backup copy of the VM in the replica site it can also be designated as the starting point for the initial replication.
HVR includes the necessary Windows Firewall exceptions but you need to enable them manually. In my own testing of setting up HVR it was a remarkably simple process, the fiddly bit was setting up the X.509v3 certificates in each end but that was because I was using self-signed certificates. In a production environment with third party certificates the whole process (apart from the initial replication) can be done in less than ten minutes.
Once the initial replication is complete the first step you should take is to do a Test Failover on the replica host which will start the VM (with "–Test" added to its name) to make sure application and services work as expected.
If you have sufficient warning that a site is about to be hit you can perform a Planned Failover after first shutting down the VM, this will complete all replication so no data is lost. If on the other hand a sudden issue has hit a site you have to perform a Failover on the replica server and there's the possibility of data loss if some changes didn't replicate across before the disaster. Optionally you can also enable Reverse Replication of the VM back to the original host if it's available.
 |
Figure 3. With alternative TCP/IP settings configured, HVR will automatically inject these IP addresses into the VM when it's started in the replica site. (Click image to view larger version.) |
HVR allows you to configure different IP addresses for the VM to use on the primary and replica host but there's no inbuilt mechanism to change DNS records, this has to be done manually. Be aware that whilst the VMs on the replica host aren't running and are thus not consuming CPU and network resources if you have a lot of them you need to size your storage accordingly as their VHD(X) files are written to almost continually.
While some of these limitations of HVR may be a show stopper for enterprise size environments, the simplicity of setup and ease of management that HVR offers makes it ideal for SMB.
More on this topic:
About the Author
Paul Schnackenburg has been working in IT for nearly 30 years and has been teaching for over 20 years. He runs Expert IT Solutions, an IT consultancy in Australia. Paul focuses on cloud technologies such as Azure and Microsoft 365 and how to secure IT, whether in the cloud or on-premises. He's a frequent speaker at conferences and writes for several sites, including virtualizationreview.com. Find him at @paulschnack on Twitter or on his blog at TellITasITis.com.au.