Enable nested virtualization on Windows 10 Enterprise

It is now possible (and supported) to run nested virtualization hosts such as Hyper-V and VMware ESXi. This is enabled on a per-VM basis using the following command, please note that the VM must be in the powered off state before this command will work.

Set-VMProcessor -VMName DcLabServer01 -ExposeVirtualizationExtensions $true

When you try to install Hyper-V on a VM the role will fail to install unless this has been configured on the host. It is supported on Windows 10 as well as Server 2016.

Deploying Nano Server on Server 2016 as Hyper-V Hosts and Domain Join Nano Server with djoin.exe

The new server deployment option Nano Server can be used for Hyper-V hosts (along with other roles), it feels like Microsoft's attempt of getting Hyper-V closer to an appliance than a Windows Server. The Nano Server Recovery Console feels a bit like the DCUI for VMware ESXi. I was recently playing with Nano Server with the intent of deploying a two-node Hyper-V Cluster using it.

The Nano Server Image Builder (which required the Windows 10 ADK) is very effective at creating Nano Server images. It also generates the raw code used by the tool in order to do that. This code creates a new Nano Server VHDX with Containers, Hyper-V and Shielded VM support. The Image Builder makes generating these scripts remarkably easy.

New-NanoServerImage -MediaPath 'F:\' -Edition 'Datacenter' -DeploymentType Guest -TargetPath 'E:\Virtual Machines\Virtual Machines\NanoServer.vhdx' -MaxSize 8589934592 -SetupUI ('NanoServer.Containers', 'NanoServer.Compute', 'NanoServer.ShieldedVM') -ComputerName 'nanoserverlab01' -SetupCompleteCommand ('tzutil.exe /s "SA Pacific Standard Time"') -LogPath 'C:\Users\ryan_betts.MEGATRON\AppData\Local\Temp\NanoServerImageBuilder\Logs\2017-02-13 15-47'

Nano Server has almost no local logon capabilities for configuring Hyper-V etc, so everything should be done remotely. This is easy if the Nano Server hosts are joined to the AD domain. The Nano Server Image Builder offers you the ability to pre-join Nano Server instances to an Active Directory domain. For this to work, you must first pre-create the computer object in AD using djoin.exe. 

The following command can be used to do this, it will only work if the server running the Nano Server Image Builder is joined to the destination domain. I am sure you could get around this with djoin blobs etc. 

Djoin.exe /provision /domain ryanbetts.co.uk /machine nanoserver02 /savefile offline.txt

One the Destination Machine Information page the Nano Server computer name must match the predefined computer object name for the process to work.

Select the Domain Join option, this is the part that will fail if you are not building the Nano Server VHD from a device that is joined to the destination domain.

Once you have created a new VM and attached the Nano Server VHD it should be pre-joined to the domain and it should let you login using Domain Admin credentials.

Hyper-V 2012 R2 "The operation failed. Failed to create external configuration store at local path: The system cannot find the path specified...(0x80070003)"

When you try to create a new VM using either Failover Cluster Manager or the Hyper-V Manager you get the following error when you click Finish to actually create the VM. In this environment the new VM function was working correctly last week.

It is a simple fix but it took me a while to work out why it suddenly started happening. It turns out it was related to the Hyper-V Settings and the default location for Virtual Machines. In this example I was using a two node Hyper-V Cluster with shared storage. 

It seems that if you have the default Virtual Machines location set to a local path you will get the 0x80070003 error. When I was trying to create the new VM, I was pointing it to a LUN hosted on a HP StorVirtual. After I set the default Virtual Machine path to point to the same shared storage it worked correctly.

SCVMM 2012 R2 - Joining Hyper-V 2012 R2 Host to Host Group fails with "error 415 agent installation failed copying"

Trying to join a Hyper-V host to a VMM 2012 R2 Host Group fails with;

"Agent installation failed copying C:\Program Files\Microsoft System Center 2012\Virtual Machine Manager\agents\Amd64\3.1.6011.0\vmmAgent.msi to \\HyperVHost\ADMIN$\vmmAgent.msi.

The network path was not found."

This was because I forgot to add the VMM Run As account to the Local Administrators group on the target Hyper-V server.

Hyper-V 2012 R2 Hyper-V Replica – Overview and Configuration

I am having to re certify my MCSE Server Infrastructure in the next couple of weeks so I really need to skill up on Hyper-V and understand what it can do in 2012 R2. I tend to always favour VMware in production deployments.

Overview of Hyper-V Replica on Windows Server 2012 R2

Hyper-V Replica is a technology that allows virtual machines (VM’s) to be asynchronously replicated between Hyper-V hosts. Hyper-V Replica was introduced in Windows Server 2012.

Hyper-V Replica Key Points;

• ·       Asynchronous replication between Hyper-V hosts.
• ·       Supported in Windows Server 2012 and above.
• ·       Replication is achieved over ordinary IP-based networks.
• ·       Hosts can be geographically separated.
• ·       Supported along side Hyper-V clustering and without.
• ·       No shared storage is required for Hyper-V Replica.
• ·       Hyper-V hosts do not have to be domain joined.
• ·       Hyper-V hosts can be domain joined, and reside in different forests.
• ·       Authentication between hosts can be done with certificates and Kerberos.
• ·       Hyper-V Replica can be used in conjunction with Azure ASR.
• ·       Replication cycles can be configured at 30s, 5mins or 15mins.
• ·       Hyper-V Replica traffic can be tagged using Trusted Groups for multi-tenant environments.

Hyper-V Replica seems to be aimed at the Disaster Recovery space for failover at site level to a DR DC. Although in some smaller organizations it can be used as failover between two Hyper-V hosts, when expensive SAN’s etc. are not available.

However, if you plan to use Hyper-V Replica as “cheap” failover, please bare in mind it’s not automatic. A manual step is required in order to cutover to the replica host. You can however perform test failover scenario’s so that you can effectively test your DR solution.

A log file is maintained by the Hyper-V Replica service to ensure the last changes are played back to the replica VM’s, this is done based on the replication cycle time you configure.

Configuring Hyper-V Replica on Windows Server 2012 R2

From the source Hyper-V host click Enable Replication from the Actions menu. Click Next on the introduction page.

Click Browse and find the destination Hyper-V host you are going to enable replication to. Click Next.

If you have not configured Hyper-V replica on the destination server you will receive the error “The specified Replica server is not configured to receive replication from this server.” the option to Configure Server… will appear.

This will display the Hyper-V Settings for the destination host. Click Enable this computer as a Replica Server. and then tick Use Kerberos (HTTP), I am going to cover the integration of certificates in a separate post.

Scroll down the windows and click Allow replication from the specified servers and click Add, from here enter the name of the source Hyper-V host. You will also be prompted to create a new Trust Group. A Trust Group is a form of Authorization which contains servers that are allowed to replicate between each other. 

As Kerberos is using TCP port 80 you must ensure that there is an incoming rule, bound to the domain profile for the source/destination servers.

One important thing to remember on the Replication VHD’s page, is that if you have Hyper-V Replica configured on a VM and you add additional disks to it at a later stage Hyper-V does not detect this can it will not automatically start replicating the new disks. You must reconfigure the replication to include the new disks.

The frequency you select will depend upon your RPO/RTO requirements. In most cases 30 seconds maybe a little excessive, as it will generate a very high amount of network traffic. By default, replication traffic is sent over the management interface.

Hyper-V Replica can be configured to store multiple recovery points; this allows you to store multiple versions of the server for more options to roll back.

Initial Replication can be configured, it’s worth knowing that if you have a large amount of VM’s with large data sets you can stage the data onto an external disk. 

You can monitor the initial replication status of the VM.

Once it’s completed you can view the status of the replication from the destination server, under the Replication tab.

Replication health can also be checked from the source server if you right click the VM and select Replication > Replication Health.

You can perform planned failovers to the replica VM if you require, for example you may have to take the source Hyper-V host offline for patching. Please note that your failover will not work if you do not have the Virtual Networks configured correctly on both side. You must have a Hyper-V Switch configured on both Hyper-V hosts with EXACTLY the same name, from a networking perspective this switch must be uplinked to the correct physical network segment to allow the VM to continue working properly.

A VM must be powered off to perform a planned failover, once it’s off you should be able to failover the VM instance.

Hyper-V Failover Clustering in Windows Server 2012 R2 - Overview

Hyper-V can be deployed in conjunction with the Failover Cluster server role in Windows Server 2012 R2, to achieve a highly available and resilient virtualization platform. Hyper-V Failover Clusters allow the movement of VM’s to neighbouring Hyper-V hosts within a cluster, this protects against host failure and also provide flexibility when performing updates and patches of the underlying host operating systems.

In the event of a node (Hyper-V host) failure the Failover Cluster Service will automatically failover or “cut over” the VM’s running on that node to another one of the nodes in the Failover Cluster. It should be noted that this does not provide instant failure, there is a short amount of latency between a host failing and the VM’s being started on another node.

The following are some key points relating to Hyper-V Failover Clusters if you are considering them for your infrastructure;

• ·      Cluster node to node communications should be on a separate network segment.
• ·      Hyper-V failover cluster hardware must pass all validation checks for compatibility.
• ·      Hyper-V clusters are limited to 64 hosts and 8000 VM’s.
• ·      Network interface card settings should be identical across hosts and switches.
• ·      DNS must be configured on each cluster host.
• ·      Private cluster networks should not be routable.
• ·      Private cluster networks should use unique network segments ranges.
• ·      Hyper-V hosts should be in the same Active Directory domain.
• ·      A single Hyper-V host can run up to 1024 VMs concurrently.
• ·      Shared storage is required for a failover cluster, SMB shares can be used.
• ·      Virtual Networks on Hyper-V hosts must be named exactly the same on clustered nodes.
• ·      Cluster Shared Volumes (CSV’s) are required for clustered VM’s.
• ·      The Hyper-V integration services are required on clustered VM’s.
• ·      Hyper-V QoS can be used to reduce the number of physical NIC’s required for different traffic types.

    You are probably comparing Hyper-V to VMware vSphere, it is a matter of opinion on what product is the best. I believe vSphere is a more mature product at this point in time.  Although in Windows Server 2012 R2 many of the most commonly used features are available in both, for example at one stage VMware’s Distributed Resource Scheduler, that automatically load balances VM workloads across clustered ESXi hosts was not something Hyper-V could do. Now with Hyper-V 2012 R2, VMM and Live Migrations there is a very similar service available that boasts “no noticeable” downtime whilst migrating.