Generation 2 VMs – The new type of virtual machine.

With the release if Microsoft Windows Server 2012 R2 there will be two options when you come to create your VMs – Generation 1 or Generation 2 VMs.

Generation 1 VMs are the ones you have been use to since the release of Hyper-v with Windows Server 2008. With Windows Server 2012 R2 you will have the option of choosing a generation 2 VM, this will give you several benefits including:

  • Emulated devices have been removed
  • Allows for boots from virtual SCSI
  • You can boot from synthetic network adapters
  • Boot from UEFI instead of BIOS
  • UEFI secure boot is enable
  • You can run Gen1 and Gen2 VMs side by side#
  • No performance improvements on Gen2 VMs. Having said that booting is around 20% faster and OS install can be 50% faster.

If you look at a Gen1 vs. a Gen2 settings screen below (Gen1 is on the left with Gen2 on the right) for Hyper-V you will notice a lot of the options you are use to appear to be ‘missing’. This is because things such as the IDE controllers are no longer needed – you can use the SCSI controller to boot! Other options that are no longer needed for Gen2 is the COM and Floppy ports. Also there are no longer any emulated devices.

Gen2 machines now fully support UEFI rather than the traditional BIOS – you can see on the Gen1 settings on the left you have the usual ‘BIOS’ options and on the Gen2 you have ‘Firmware’. With UEFI secure boot has been enabled by default to protect your VMs during the boot process.

One thing that will please a huge number of Hyper-v users will be the ability to do full PXE booting – you no longer need to use the emulated network adaptor (emulated network no longer exists) you have the full network bandwidth.

image

As mentioned above, Hyper-v Gen2 machines no longer need emulated devices. You can see this below with the device manager. Again Gen1 is on the left with Gen2 on the right. The Gen1 clearly shows the emulated devices under the PCI to ISA bridge (Microsoft used the ISA bridge to prevent the need to consider Plug n Play).  With the Gen2 device manager you can see all the devices are running through the native VM Bus.

image

Finally one feature that I have been waiting for since working with Hyper-v although very trivial is copy and paste. Hyper-v will now allow you to copy and paste text and even files both ways between VMs (just like with RDP). Sound is also now available within the VM – play a video in the VM and hear the sound on the local machine.

As always though there are some gotta’s with this new technology. You must be running at least Windows Server 2012 or Windows 8 x64 operating systems and once you have made the decision on the generation of VM you want to use you can’t change it.

Due to some of these limitations Microsoft have stated they are aware people will need Generation1 VMs for quite some time so these traditional virtual machines you are use to and all the settings that go along with them are not going away anytime soon. Having said that if you are using Windows Server 2012 (R2) or Windows 8 (.1) Generation 2 is worth a look.

Advertisements

Change the VMSwitch of all VMs on a host.

I had a requirement today to change the VMSwitch associated to all the VMs on my Hyper-v host. Obviously if you had time on your hands an really wanted to you can go through and change each one individually with the mouse but far more efficient would be to use PowerShell!

I started off with a:

Get-VM | Connect-VirtualNetworkAdapter –SwitchName “MySwitchName”

This won’t work though as you can see here the -VMName does not accept a piped input.

All you need to do though is just use a wildcard (*) for the VMName instead:

Connect-VirtualNetworkAdapter –SwitchName “MySwitchName” -VMName *

And instantly all your VMs will be on the new adaptor.

The Power of PowerShell 😀

Hyper-V Replica Capacity Planner

Windows Server 2012 introduced a new feature for  Hyper-v  – the Hyper-v replica. As discussed here Hyper-v replica allows you to replicate virtual machines to a secondary or offsite data centre to allow for easy disaster recovery.

Microsoft have now released a capacity planner which will be useful especially if you are working with a third party so you can keep costs for offsite hardware to a minimum.

You can download the capacity planner for here >> http://www.microsoft.com/en-eg/download/details.aspx?id=39057

Error (0x0107, 0x0000) when trying to view a VM Console

I wanted to create a quick post about this just in case anyone else  ever has a  (0x0107, 0x0000) message when trying to view a VMs console session using VMM 2012.

Capture

This happens when you have a untrusted Hyper-V host in VMM 2012 such as a machine sitting in your DMZ (perimeter host). You will be able to see the Hyper-V host, the VMs and manage the VM properties but not connect to the console.  When you try to connect to the VM you will be asked to authenticate against the host and then you will see a warning about an un trusted certificate and once you click OK you will receive the (0x0107, 0x0000) message.

RDP

To resolve this issue you need to import the certificate from the Hyper-V host onto the machine where you are running the VMM console.

Logon to your Hyper-V Server and create a new MMC Console. Select the Certificates Snap-In to add use the ‘Services Account’

Step1

Locate the ‘Windows Remote Management (WS-Management)’ service account and complete the wizard with the rest of the defaults.

 

Step2

If like me your Hyper-V host is running Windows Serer Core mode instead of using certutil.exe you can use a snap-in on another machine (you will be asked to authenticate against) to remotely manage your certificates.

Once you have the console setup you need to find your server certificate which will be located under ‘WinRM\Trusted Root Certificate Authorities’. Right click on the certificate and follow the export wizard.

Step3

On your VMM console machine you need to import the certificate you have just exported into the ‘Trusted Root Certificate Authorities’ of the computer account.

STEP4

You should now be able to connect to the console of the VM. You will still need to enter your authentication details but you won’t be presented with the certificate warning.

Hyper-V & SMB Direct (RDMA)

Windows Server 2012 brings an update to SMB which has so many new features in it Microsoft have bump it up an entire version and call it SMB 3.0. Many of the new features included in are there to directly improve your experience with Hyper-V.

Hyper-V now supports your using SMB storage for your virtual machines which opens up whole new possibility for deployment scenarios, which will benefit not only large corporates but will also make highly available virtual infrastructures available for the smaller customer without the costs of dedicated SANs and complexity of fibre and iSCSI LUNs.

One of these new SMB 3.0 features is SMB Direct which makes use of RDMA (Remote Direct Memory Access). RDMA  allows for computers on the network to send and receive data without having to use processor time, interrupt the OS or cache. This obviously aids with VM density – you will be able to have more VMs on your host machine as the processor won’t be so tied up with network operations but also allows for data transfer with very high throughput with ultra low latency.

RDMA works by using a protocol on the NIC (you need to make sure you purchase an RDMA NIC – both servers will need an RDMA compatible NIC) if this hardware is in place is makes it possible for one computer to directly read data and write data to another computers memory.

As mentioned above you need to have the correct hardware in place and that involves having the right NIC which re sometimes known as R-NIC. There are currently three different types available from various different manufacturers. The three types are: iWARP, RoCE an Infiniband.

Setting up your server infrastructure to support this could not be simpler – you don’t need to do anything! When two computers start to talk they make a standard connection via TCP, once the connection is established they share information about what they are capable of doing (data transfer also beings at the same time so there is no overhead or latency) once both computers have decided they are both capable of running SMB 3.0 and have RDMA capable hardware they will seamlessly switch.

Using some of the new NICs that are available from vendors such as Mellanox (the ConnectX-3) you are able to get incredible speeds up to 56Gb/s!!! when using Infiniband. These are some amazing speeds but when you start to pair this with SMB 3.0’s new multi channel feature and Windows Server 2012 network teaming capabilities the speeds possible really are incredible. Jose Barreto who works on the file server team at Microsoft has a blog post on how to configure the Mellanox.

Microsoft presented some stats on how using SMB data storage with RDMA performs which are defiantly worth having a look at.

I would be very interested to hear from people who have started to play with technology and see how you are finding it in a real world environment.

RDMA compatible NICs are defiantly something to add to your shopping list next time you are purchasing server infrastructure.

Hyper-V Replica in Windows Server 2012 – Amazing!!

UPDATE – Have a look here for some of the new features that Windows Server 2012 R2 will bring to Hyper-V Replica (its even more amazing Open-mouthed smile)

Hyper-v replica is one of the most highly anticipated features of Windows Server 2012. With it comes a whole new range of DR possibilities, something that would have not been possible or taken a large amount of money to achieve is now free and in the box!

The basic concept of Hyper-V replica is, as the name suggests, to replicate VMs from one site to another (or one live server to a backup server on the same site). Some of the possibilities that come to mind is the ability to replicate branch office VMs back to the main office location or from a main office up into the cloud to easily and very quickly recover in a DR situation.

How does replication work?

I have heard people when describing Hyper-v replica say ‘we can already do this with DFS’ – you can’t! DFS will only replicate a file when it has been closed and no longer in use (also Microsoft does not support using DFS to replicate VHDs /VHDXs for this purpose even if you turn the VM off).

Hyper-v replica is able to replicate the files even when they are in use in your production environment. Replication is achieved by an initial replica (IR) of your data being replicated from the primary server to the replica server (this can either be over the wire or a copy can be copied to physical media, taken to the backup server and then copied onto it. Once you have the initial copy in place, the primary server makes use of a change tracking module which keeps track of the write-operations that happen in the virtual machine.

Every 5 minutes (this is none configurable at present) a delta replication will take place. The log file being used is frozen, a new log file is created to continue tracking changes and the original log file is sent to the replica server (provided the last log file was acknowledged as being received). The changes can be seen by looking in the Hyper-V Replication Log (*.hrl) that is located in the same directory as it is associated to.

Types of delta replicas

There are a few options for the delta replicas. In the most simple case you will have selected ‘Store only the latest point for recovery’, in which case all of the replication log data is merged into the VHD file that was initially replicated to the Replica server.

The second possibility is that you have chosen to store multiple recovery points in which case when the log file is received every 5 minutes these are stored and every 1 hour / 12 log files (again this is none configurable) a snapshot is created to which the log files are written. The number of snap shots is determined by the number of recovery points you opted to keep when replication is configured. Once the limit is reached, a merge is initiated which merges the oldest snapshot to the base replica VHD.

The third possibility allows for an application consistent snapshot to be created. Application-consistent recovery points are created by using the Volume Shadow Copy Service in the virtual machine to create snapshots. The log file are sent every 5 minutes as with the two examples above but as the 12th log arrives the log files will create a snapshot (as above) and the snap shot will the app consistent (if you chose for an app consistent every 2 hours every other snapshot would be app consistent etc.)

If at any time on the Primary Server a new log cannot be created, changes continue to be tracked in the existing log and an error is registered. Replication will be suspended and a Warning is reflected in the Replication Health Report for the virtual machine.

Clustered Replica Servers

If your replica server is part of a cluster you may want to move the Replica VM from one node to another (or it may move automatically by use of VVM). To keep track of where the replica VM is the VMMS (Virtual Machine Manager Service) uses a new object called the Hyper-V Replica Broker Manager.

Hyper-V Replica Communications

Communications Architecture

Communications Architecture

The replica communications is achieved by the use of the ‘Hyper-V Replica Network transport layer’. This transport layer is responsible for authorizing access to a Replica server as well as authenticating the Primary and Replica servers. It also provides the ability to encrypt (if you are using a certificate), compress and throttle (with the use of QoS) data that is sent by the primary server.

The first connection to be made between the Primary Server and the Replica server is the ‘control channel’ the Hyper-V Replica Network Services checks to see if a control channel exists – if it does it will use it, if not it will create the connection and then transmits a control message which contains a list of files that will be sent from the Primary server to the Replica server (this is used if data transfer is cancelled mid-way through). Hyper-V Replica Network Services on the Replica server forwards the package to the Hyper-V Replica Replication Engine, which then sends a response back which contains information about which, if any, of the files already exist within a timeout interval of 120 seconds.

Once the control message has been acknowledged as being received by the Replica server data transfer can begin. This data transfer is done over a different connection to the control channel – called the ‘data channel’. The files to be transmitted will be either for an Initial Replication or for a Delta Replication. The Hyper-V Replica Network Service layer chunks the data into 2 Mb chunks and compresses it. Once the data chunks have been received by the Replica server they are decrypted and put back together before being saved to the save location specified for the replica virtual machine.

Hyper-V replica handle virtual machine migrations from one host to another and even storage migration during a data transfer. If migration of a virtual machine takes place while data transfer is in progress the Hyper-V Replica Network Service closes any open connections and will automatically re-establish connection with the Replica server once the migration is complete. The control message is used to do a comparison to see which files were missed due to the cancelled connection. The exact same procedure is used if a storage migration is carried out during a data transfer.

Configuring Hyper-V Replica

Hardware Requirements:
This is fairly simple – all you need is two servers capable of running the Hyper-V role. The replica site is completely hardware and storage agnostic.

Software Requirements:
Again there is not much to this – obviously Windows Server 2012 is required and also if you want to encrypt the data during transmission (defiantly recommended if you are replicating offsite to a DR center for example) you will need a certificate which can either be self-signed or provided by your PKI infrastructure.

There are two possibilities for the Replica server – either stand alone or a failover cluster.

To configure a standalone Replica server:

  1. Right click on the Hyper-V server on the Hyper-V Manager and ‘Hyper-V Settings’
  2. Click on ‘Enable this computer as a Replica server.’ You will need to do this on both the primary and Replica servers.
  3. Next you have a couple of options for authentication you can use Kerberos or an SSL certificate. To further enhance security you can select the servers you want to allow replication from. You can select any server or you can be more restrictive and specify servers by wildcard e.g. *.contoso.local or by actual server name MANHYP01.contoso.local.
Replication Config

Replication Configuration

  

To configure clustered Replica servers:

  1. Install and configure your failover cluster as you normally would and ensure you introduce enough nodes into the cluster to meet the demand.
  2. Once you have the cluster in place and configured as required right click on your cluster and go to ‘Configure Role’
High Availability Wizard

High Availability Wizard

  1. You will need to specify a NETBIOS name for the broker service that      you will use as the Client Access Point when configuring the VMs for      replication. This will create a computer object in AD for you.
AD Computer Object

AD Computer Object

  1. Next, right      click the Replica Broker you created and click on ‘Replication Settings’
Replication Settings

Replication Settings

  1. You will then see the configuration wizard as in the standalone configuration. You can select http or a certificate based authentication (this depends on if the remote cluster is part of the same domain or has a trust in place – if not you will need to use a certificate based approach) You can as before also select the servers that are allowed to replicate by server name or wildcard and you can select the security tag to use.
Authentication

Authentication

  1. Once the server is configured for replication you can then enable replication a per virtual machine basis. Instead of selecting the physical server to migrate to you need to select the Client Access Point e.g. in my case ‘HyperVReplica’.
Replica Server

Replica Server

Replication from this point on works in exactly the same way as described earlier with the log files being transmitted every 5 minutes. The newly created virtual machine on the Replica server will be made highly available.

Folder Structure for Hyper-V Replica

The standard folder structure you are used to with Hyper-V is created with the addition of a folder called ‘Hyper-V Replica’ with several subfolders as seen below (The Snapshots folder is only created if recovery history is enabled) with each of the virtual machines being identified by its GUID.

Storage Paths

Storage Paths

Networking with Hyper-V Replica

In a real world situation you would most likely be replicating your virtual machines off site to another office or to a partners DR facility over a WAN connection. The network addressing schema will obviously be different at this site and will cause problems for your users trying to access your servers. Microsoft has thought about this and has included the ability to configure different network settings at the Replica site.

Replica Network

Replica Network

To configure this you need to modify the virtual machine properties of each machine and each of the virtual adaptors connected to the machine. This is only available on synthetic network adaptors – you can’t set this for legacy adaptors. The only other pre-requisite for this to work is that your virtual machine must be running any of the following OS’s Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 SP2 (or higher), Windows 7, Vista SP2 (or higher), and Windows XP SP2 (or higher). The latest Windows Server 2012 Integration Services must be installed in the virtual machine.

Using Hyper-V Replica

Once you have all this in place and you are successfully replicating your VMs to another stand alone or cluster server you have a few ways to move over to your replicated VMs.

Planned Failover – A planned failover allows you to failover to your Replica VMs in a planned and controlled manor. This can be used if you have prior warning of an event that you know is going to cause potential problems to your primary datacenter such as a power outage or natural disaster etc.

In a planned failover reverse replication must be enabled (this is checked as a pre-requisite) so that when you failback your Primary VMs are up to date. The second pre-requisite to a planned failover is that the VMs must be shutdown prior to the failover taking place. Due to this a planned failover does require a small amount of downtime but no data will be lost.

Test Failover – A test failover is a good way to test your DR plan. When you initiate a test failover a new virtual machine is created on the replica server with the name <your VM name – Test> This VM is added to a different network (You can specify a test failover network on the VM properties) this is so it will not affect your live production environment. You can add a few test workstations to this test network and check everything works as required.

Test Failover Network

Test Failover Network

This type of failover does not require any downtime of your live production machines and so can safely be carried out during the working day.

The final failover is the un-unplanned failover – the one no-one wants!

Unplanned Failover – An un-planned failover is as the name suggests. This can happen if you have a hardware problem in your main datacenter or an environmental problem – failed generator during a power outage or failed air-conditioning unit (from experience!) and no redundancy. This allows you to bring up your replica VMs and get your users up and running very quickly. When you’re primary datacenter is up and running again you can simply replicate the VMs back and get everything back to how it was.

Although this is a great additional to a DR policy by no means is it a replacement to you back routine! You MUST continue to preform your backups as you are now.

Domain Controller Cloning & Snapshot Safeguards with Windows Server 2012

There have been a few enhancements made to the domain controllers’ role in Windows Server 2012. Two of the interesting ones I like is the ability to clone domain controllers e.g. if you need to deploy a new DC into your environment you no longer need to build a server, run a DCPromo etc. just simply copy the VHD of an existing DC and create a new VM! (You do need to do a few pre-requests first). The second feature I like is that DCs have some intelligence built into them so they know if they have been reverted to an earlier snapshot or had its VHD copied and put into production.

This second enhancement is a great improvement, before Server 2012 if you restored an earlier snap shot you would have a huge Active Directory mess to sort out (if you could sort it out at all) and it would take hours of work usually involving an expensive support call to Microsoft. As virtualizing domain controllers is becoming more common so was the problem.

These two enhancements are possible as the active directory team has been working closely with the Hyper-V team. They have come up with the idea of a new ‘VM-Generation ID’ which has been added which is stored in the non-replicated attribute DC’s computer object. This ‘VM-Generation ID’ is a unique 128-bit identifier that guest operating systems and applications can leverage. The domain controller will use this ‘VM-Generation ID’ to be sure nothing has happened to it, which it does not know about.

Cloning a Domain Controller

 First let us have a look at the ‘DC Cloning feature’:

Of course there are some requirements that must be in place for all of this to work but nothing too in-depth.

  • First you must be running a 2012 PDC.
  • Secondly you need to be running these VMs on Hyper-V 3.0 (Windows Server 2012 version). This is because when the VM is starting it checks the ‘VM-Generation ID’, of the virtual machine, if it  detects this is different to what it was expecting and the DCCloneConfig.xml is present (more on that in a minute) then it knows it has been cloned.
  • The final requirement is for you to add it to a new group called ‘Cloneable Domain Controllers’ unless it is part of this group you will be unable to complete the clone process – you will get an error when running the power-Shell command.

Once everything is in place you are all set to create a DC clone. Here are the steps to very quickly create a new DC in your environment.

  1. Find a suitable 2012 DC to clone.
  2. Add the DC’s computer account object to the group ‘Cloneable Domain Controllers’

Run the PowerShell Command:
 ‘Get-ADDCCloiningExcludeApplicationList’
  • One further requirement is that this DC is not running any ‘un-cloneable’ applications. This command will look though everything that is installed and will check it against a list of applications in its whitelist. You can manually add applications to this list if you need. The default location of the XML list is: %windir%\System32\DefaultDCCloneAllowList.xml. If you do have any applications that aren’t in the white list you will be shown a list that you need to resolve. All of the obvious ones you will usually find on a DC such as DNS, DHCP, FRS and DFRS are all included in the whitelist by default.

Once all of that is in place you are ready to start the clone. Again this is done with PowerShell – surprise, surprise!! The command you need is: ‘New-ADDCCloeConfigFile’.
This generates a configuration file that the server will look for when starting. You have several switches you can run at this point if you want to specify the computer name, DNS & IP etc. or you can just leave it blank. Some of the available switches are:
  • -CloneComputerName
  • -IPv4DNSResolver
  • -Path
  • -SiteName

By default the file will be saved to %windir%\NTDS and is called ‘DCCloneConfig.xml’. (If the server detects that it is a cloned VM as the ‘VM-Generation ID’ has changed, but it can’t find the ‘DCCloneConfig.xml’it will look in the root of removable drives, if it still can’t find the file the server will boot into ADRS and await further instruction.)

Next, shut down the machine, copy the VHD, attach it to your new machine and boot it.

If everything has gone to plan you will see this screen while the server boots. Once complete you have a new fully functional DC up and ready to go.

At this point the server calls SysPrep providers for select components to cleanup machine state. Next it will reset the identifier (invocationID) to ensure replication can complete and Invalidates RID pool eliminating potential for duplicate SIDs. If the source was a FSMO role holder the FSMO role is discarded.

You can just boot the machine you shut down to create the clone from. This machine will boot up and rename the ”DCCloneConfig.xml ‘ file by appending the date.time to the end and will then carry on as if nothing had happened.

 

Restoring a Domain Controller snap shot

As mentioned earlier there is a second enhancement to virtualized domain controllers, you now, no need to worry about someone creating and restoring a snap shot of a virtual domain controller – Microsoft have you covered there too!

The problem was that when you restored a snap shot you would restore the RID pool back to what it was when the snap shot was taken. You could have added hundreds or even thousands of changes since then (depending on the size if your organization). This would lead the server to start assigning new accounts the same SID which would cause security risk – the two accounts now have the same SID – so they have the same permissions! They would be able to read each other’s files and access each other’s folders. This would be a temporary problem as active directory would eventually detect this and would then disable the affected accounts. This would lead to hundreds or thousands (again depending on the number of users in your environment) of support calls to your helpdesk.

The second problem that would be caused is that the same USNs (update sequence number) would be used which means that when the DC tried to replicate with other DCs on the network they would accept all of the updates. This would lead to lingering objects, mismatched passwords and incorrect group membership depending on the DC the user tried to authenticate to.

This slide taken from a Microsoft TechEd presentation is a good one for showing the problem:

With Server 2012 and the use of the ‘VM-Generation ID’ this would not happen as show below:
 

We can see this in action for ourselves. This is before the snap shot has been taken and shows when the RID pool was created and changed as well as the nextRID ID

Next several accounts are created so that we start to deplete the RID pool:

And finally the original snap shot is restored and as you can see the RID pool NextRID is the same as before the snap shot was taken! This in a live production environment would cause serious problems.

We can now compare this to what would happen if the same procedure was completed on a Windows Server 2012 domain controller.

Again, before the snap shot is taken we can see the RID pool ‘NextRID’ value and the date of creating & changing for the RIDPool.

Next we create the new accounts and we can see the RID pool has been depleting as the new accounts are created.

Finally we restore the snap shot and we can see that Server 2012 has detected this has happened and marked the RID pool as being bad. The server then contacted the RID master and requested a new RID pool.

So in summary before any changes are made to the local active directory database the server checks to see what its ‘VM-Generation ID’ is, if it is not what it is expecting then it will do several things.

  • The first thing that will be done is the local RID pool will be invalidated and a new RID pool will be requested from the RID master.
  • Next the invocation ID will be increased so that the when replication happens even though the USN would be the same the domain controllers invocation ID would be different meaning the other domain controllers would accept the update and replicate.

This is definitely NOT a replacement to backups – you should still carry on backing up your domain controllers as you currently are. I will write a post about how this can simplify a DR situation at a later date.

As a side not this will only work with Hyper-V 3.0 if you are running your domain controllers on VMware or XEN servers then I’m afraid you can’t take advantage of either of these features. Microsoft have said they are working with VMware to I wouldn’t be too surprised to see this available in the future.

This is a great new addition to server 2012 and just goes to show that Microsoft have been listening to customer feedback and watching support calls to see how they can help customers.