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.

Windows Server 2012 R2 & Syetem Centre 2012 R2 Preview

Microsoft has now made available the download links for people wanting to try out Windows Server 2012 R2 and the new features that were announced at TechEd North America a few weeks back.

There are four different versions available depending on your need. It is worth noting that these versions will expire on January 15, 2014.

Also available today are the preview versions of Microsoft’s System Centre Suite 2012 R2 & SQL Server 2014.

All the download links are available here >> http://technet.microsoft.com/en-au/evalcenter/dn205292.aspx?CR_CC=200142594

Hyper-V Management Pack Extensions 2012

Although the Hyper-v 2012 management pack available for SCOM 2012 is very good at monitoring Hyper-v (http://www.microsoft.com/en-us/download/details.aspx?id=36438) people over at CodePlex (a site dedicated to open projects you can participate in) have released another management pack with some additional features.

Some of these additional features are:

    • VMs Integration Services Version monitor
    • Hyper-V Replica Health Monitoring Dashboard and States
    • SMB Shares I/O latency monitor
    • Hyper-V Hypervisor Logical processor monitoring
    • Hyper-V Hypervisor Virtual processor monitoring
    • Hyper-V Dynamic Memory monitoring
    • Hyper-V Virtual Networks monitoring
    • NUMA remote pages monitoring
    • SLAT enabled processor detection
    • Hyper-V VHDs monitoring
    • Physical and Logical Disk monitoring
    • Host Available Memory monitoring
    • Stopped and Failed VMs monitoring
    • Failed Live Migrations monitoring

Find the management pack here >> http://hypervmpe2012.codeplex.com/

As usual with this type of software – you should test it fully before being used in a production environment.

Microsoft Announced Windows Server 2012

No great surprises really but at TechEd North America Microsoft has announced that System Centre R2 and Windows Server 2012 R2 will be made available.

When Windows Server 2012 RTM was introduced, Microsoft announced it as their ‘Private Cloud’ operating system. With Windows Server 2012 R2 they have started to introduce more of a ‘hybrid cloud’ feel making it much easier to migrate from on premise to off premise and into, surprise, surprise Windows Azure.

What’s new or improved!?

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/MDC-B205#fbid=-V1CX7onn2V

This is just an overview of some of the new or improved features:

 

Hyper-v Network Virtualization:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/MDC-B216#fbid=-V1CX7onn2V

Teaming

With Windows Server 2012 Microsoft addressed a long outstanding problem – NIC teaming. Until 2012 RTM Microsoft did not support any kind of 3rd party NIC teaming so instead they built their own. It had some great features (have a look here for a full list) and has been heavily used by Windows Server 2012 customers. R2 brings new functionality such as “Flowlets” (Microsoft’s name for it) – traffic is now spread evenly over all NICs in the team.

Extended ACLs

Windows Server 2012 RTM featured the ability to block or allow traffic based on the source and destination VM. In 2012 R2 you will be able to take this a step further and block or allow traffic based on the actual workload. This works by having the ability to perform stateful packet inspection on the fly. The traffic can now be accessed on network address, protocol or even port.

Network Virtualization

There have been great improvements in the network virtualization capabilities within 2012 R2. Windows Server 2012 was really built (and marketed) for Private Cloud, with R2 there is much more focus on service providers and making it easier for them to host multiple tenants. The advances in network virtualization really prove this. I’ll look more at what has been done here in another post as there is so much.

One big problem with 2012 was how to break out of your virtualized network and into the ‘real world’. For network virtualization Microsoft opted to use the NVGRE protocol which needed an expensive gateway device – this is now built in and part of 2012 R2 you deploy your own gateway device onto Hyper-v! This will also support site to site VPN access to allow you to get your internal network talking to your service provider hosted VMs.

 

Improvements in Storage Spaces

For a while now Microsoft has been trying to provide a way for people to move away from large & usually very expensive SAN devices (although SANa are fully supported with features such as trim and ODX), an example is Microsoft Exchange – Its been encouraged for a while not to use a SAN and instead use DAS and DAGs for your mailbox storage. Storage spaces are another example of this. A good definition of a storage space is that it’s just like – well a SAN. In the background you have your disks (something I found interesting was that 15k SAS disks are generally 5x as expensive as 7.5k disks but only have 2x the IOPS – in other words use SSD for performance and 7.5k disks for capacity). In the foreground you have your Windows fileserver with storage spaces to carve up the disks, perform the management, provide the ability to set redundancy options such as RAID levels.

A traditional SAN storage device

A traditional SAN

A Windows Server 2012 (R2) file server with spaces

image

Of course with R2 there are a lot of new features such as:

    • Storage Tiring (New feature) – Allows you to use traditional HDD’s and SSD which allows high priority files to use the faster SSD while less important files can use the traditional HHD.

    • Data duplication (enhanced) – allows for online data duplication even when VMs are running.

    • Persistent write-back cache (new feature)

    • SMB Copy Offload (new feature)

    • Snapshots of the space

     

    Improvements in Hyper-v Replica –

    Hyper-v replica was a hugely popular feature of Windows Server 2012 Hyper-v 3.0. Some of the competitors in the virtualisation market aka VMware have allowed for replication of VMs to another site for DR for a while using products such as SRM but this is very expensive and complicated to setup. Hyper-v in 2012 had this built inbox – for FREE!

    Microsoft have improved Hyper-v replica in R2 as you would expect. You can now perform synchronization every 15 minutes, 5 minutes or even every 30 seconds. This means if you lost your primary site you would only be 30 seconds behind! Loosing 30 seconds of data would be more acceptable for many businesses especially businesses that have yet to make this jump are are still doing the old fashioned tape backups each evening – yes there are still some out there!

    Another new feature of R2 is that you can extend the replication to a tertiary site. This will be useful if you want another backup of your data ‘just in case’ but is aimed more towards service provides who offer a service for a customer to replicate to The service provider can then they can then backup your data to their DR site too.

     

    Server 2012 R2 offers some fantastic new features and really builds upon 2012 which was already a great server operating system. This new release is aimed to get service provides on board and allows you to really work towards the Microsoft vision of the cloud – that involves your provide cloud, the service providers and its Azure service.

    Update KB2506143 breaks SCCM 2012

    Microsoft have recently released (on the 12/12/2012) a Microsoft update for Windows Management Framework under the KB2506143.

    This update KB2506143 breaks SCCM 2012 (pre SP1 being installed). The latest recommendation from Microsoft is that you do not install this update until SP1 for SCCM 2012 is in place.

    System Center 2012 Configuration Manager Service Pack 1 will provide official support for Windows Management Framework 3.0 once it is released early in 2013 so is not impacted by this issue.   If KB2506143 has not yet been deployed to your System Center 2012 Configuration Manager environment then the recommended action is to wait for System Center 2012 Configuration Manager

    This happens because the SCCM client released at RTM is not compatible with Windows Management Framework 3.0. Each day the ‘Client Health evaluation’ will mistakenly find the WMI repository to be corrupt and due to the client self healing abilities built into SCCM 2012 tries to rebuild and reinstall the client.  The rebuild of the repository by CCMEval.exe causes loss of MP specific information, methods, etc., from WMI which as a result causes the MP to fail.

    An updated KB describing the problem and a work around if you have the unfortunate situation of having installed this update can be found here (KB2796086).

    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.

    RemoteFX – Windows Server 2008 R2 vs. Windows Sever 2012

    Although RDP was great in a LAN environment it was not always best suited to the WAN. Thankfully RemoteFX has seen huge improvements in Windows Sever 2012 – a noteworthy point for both CitrixHDX and VMWAre PCoIP.

    As a quick reference, some of the improvements are:

    • Support for 10 touch points in a remote session and pressure sensitivity
    • Full support for Microsoft Lync
    • True Single Sign-on
    • Complete USB Redirection – ANY USB device can be redirected to the remote session (scanner, printers, cameras etc.) and it will be secure, which means no one else will be able to access the USB devices you are redirecting
    • And the best feature – in my opinion – is RemoteFX Media Remoting

    There has been a change in protocol for some of the content transmitted if RemoteFX believes it is necessary. This will be really useful when you are transmitting a video. Traditionally RDP would transmit the video in TCP and would then re-transmit any dropped packets. However this is pointless when you are watching a fast video as by the time the packets have been re-transmitted they are no longer required –  making UDP a perfect alternative. As with all the new features this will be controllable via GPO’s so you will have complete control over what RemoteFX is doing.

    RemoteFX will now look at what it needs to transmit and optimize accordingly for example RemoteFX will send the text using a new codec that will send the data very quickly and using very little bandwidth. The images will be sent as a base jpg image and then progressive rendering will build up the image (think old fashioned web browsing) and lastly the video will be re-encoded as H.264 transmitted to the endpoint who will then de-code. If the endpoint is capable of playing video the server will not decompress the video and then transmit instead it will transmit the compressed video and allow the endpoint to decode it.

    All of this is adaptive depending on the bandwidth available so if the bandwidth is tight the host will use more CPU and being to compress more to help get the content to the endpoint as quickly as possible.

    No GPU needed! Microsoft have developed a software GPU so there will no longer be a need to purchase an expensive graphics card for your server for basic aero experience (you will still put a GPU in for CAD/CAM applications etc.) Microsoft have done this because in Windows 8 you will not be able to turn the aero interface off. The new software GPU will still have full DirectX support.

    And lastly there will be a Windows 8 Metro App (obviously!) this will be great for people who are  using this on their tablets over a 3G connection!

    All of the features mentioned above are available for both physical and virtual hosts!

    References:

    http://technet.microsoft.com/en-us/edge/technet-radio-it-time-wans-lans-and-remotefx-in-windows-server-8-beta