Microsoft News – 2 January 2015

Welcome to the “Happy New Year 2015” edition of my Microsoft News posts. I hope you have a nice time off from work – it FLEW by for me; I could do with a holiday to recover from my holiday.

Here’s the news from over the past week or so:

Hyper-V

Windows Server

  • VPN Interoperability guide for Windows Server 2012 R2: This document covers the working configurations for some of the popular third party VPN devices that can be deployed to work with Windows Server 2012 R2 VPN. The configuration for a Windows gateway is also included to server as a guideline for an interoperable deployment with the third party devices.

Azure

Miscellaneous

Windows Server Technical Preview – Cluster Compute Resiliency

Imagine a scenario:

  1. You have a cluster of Hyper-V hosts
  2. Some operator pulls the wrong network cables
  3. A host becomes network-isolated and the cluster heartbeat times out before the mistake is noticed
  4. Virtual machines fail over

Great, right? HA kicked in? That’s good … right!?!?!

Ummm maybe not. Let me ask you a question. Which is worse:

  • A virtual machine being offline for a minute or so because the host is network-isolated? OR …
  • Every virtual machine on that host stops executing, fails over to other hosts in the cluster, and takes several minutes to boot and get services responsive on the network.

For most people, option A is more favourable and this is why Microsoft is giving us Cluster Compute Resiliency.

With this new feature, a cluster will become more tolerant (and this is configurable) to transient network errors. In the event of a heartbeat timeout, the host will go into isolation. This will allow VMs on that host to continue executing and prevent additional VMs being placed onto that host. If the host becomes responsive within a certain time frame then it comes out of isolation. If the host does not become responsive then VMs are failed over to other hosts.

Note that if a host is determined to be “flapping” then it will be put into Cluster Quarantine.

Windows Server Technical Preview – Differential Export

A differential export is an export of the differences of a virtual machine from between two points in time. It is used to enable an incremental backup of a virtual machine that is backed up using the new file-based backup system with Resilient Change Tracking. The below image shows the state of a VM and its backup after a full backup. Note that this file-based backup has used Resilient Change Tracking to identify what changes are being made to the VM’s storage since the backup.

image

An incremental backup starts, using the differential export process. A backup checkpoint, including VM configuration and VHD fork (via AVHD) is created. The existing Resilient Change Tracking ID T1 is used to determine what has changed in the parent VHD to create a differential export of the VM in the backup target media (exported VM configuration T2 and the differential VHD).

image

The backup checkpoint is removed and a new RCT ID (T2) is created so we can now do Resilient Change Tracking of the VHD for the time after the backup.

image

Old reference points (RCT IDs) can be disposed of as required.

A “synthetic full backup” process is also support for third-party backup solutions.

image

Hyper-V PM Taylor Brown talks about Change Tracking in his session at TechEd Europe 2014.

Microsoft News – 19 December 2014

We’re getting close to Christmas and Microsoft is starting to wind down for the year. Here’s a mostly-Azure report for the last few days.

Hyper-V

Azure

Miscellaneous

Windows Server Technical Preview – File-Based Backup

In Microsoft endeavors to finally close the book on backup issues, the Hyper-V team is switching to file-based backup, and moving from the non-scalable VSS backup. Let’s face it – most hardware VSS Providers have been like a curse.

When you backup a VM in vNext, a “backup checkpoint” is created. This forks the VM’s configuration is forked and the virtual hard disk(s) is forked too using an AVHD. This is done for a short period of time. This allows changes to continue while the backup is being done. The virtual machine can be live exported as a backup.

image

After this operation a dateless Reference Point is created. The AHVD(s) is merged back into the parent VHD(s). This reference point notes the Resilient Change Tracking ID (per VHD), so we know what changes are made after the AVHD was created, and now we know what blocks must be backed up in a following incremental backup.

image

Some notes:

  • Incremental and “synthetic full” backups can now follow the full backup and this is done using a Differential Export.
  • A restore is basically a process of copying the VM files from backup media and importing the VM.

SAN-based backup is different. A LUN snapshot will retain the parent VHD and AVHD, and only the VM configuration is exported by Hyper-V. CDS, SMI-S or network providers be used to create the LUN backup. The LUN snapshot is removed and job done.

Hyper-V PM Taylor Brown talks about file-based backup in his session at TechEd Europe 2014.

image

Windows Server Technical Preview – Resilient Change Tracking

Windows Server Hyper-V has had an … interesting … history when it comes to backup. It has been a take-it-personally mission of the Hyper-V team to stop backup being an issue for Hyper-V customers. Backup of CSV in Windows Server 2008 R2 was not fun. Things got better in WS2012, and again in Windows Server 2012 R2. And we might finally be getting there with the next release of Windows Server.

An important change to Hyper-V backup is to enable partners to keep up with the pace of change of Windows Server – we’ve seen some backup vendors take years to catch up with a new version, and this prevents mutual customers from keeping their hosts in step with Microsoft.

In order for a backup product to do incremental backups, it needs to do block based change tracking. Each vendor has to create one of these filter drivers that sits in the storage stack. This stuff is hard to do right, and it can cause stability and performance issues if not done correctly. And it also slows down the development/re-test/re-certify of BackupProduct2016 to keep up with the release of Windows Server 2016.

Some bad change tracking implementations, that you may know of, lived in memory as bitmaps. If the host had an un-planned outage then the next backup had to be a full backup. Or maybe if the VM live migrated to another host, that VM would have to do a full backup because the change tracking was no longer in the memory of the host.

Resilient Change Tracking is built-in backup change tracking of changed blocks within virtual hard disks. It is used for incremental backup, and it is the underlying engine for differential export. The change tracking bitmap lives in memory and on-disk. The on-disk bitmap is not as granular because it is the fallback from the much more detailed in-memory bitmap.

The goal now is that backup vendors should stop writing their own filter driver to implement change tracking. If they use the built-in resilient change tracking then they can focus more time on feature development testing/certification, and keep up with Microsoft’s frequent releases of Windows Server. And hopefully, Microsoft’s change tracking will undergo suitable levels of testing that will give all customers a universally stable and well-performing subsystem.

Hyper-V PM Taylor Brown talks about Change Tracking in his session at TechEd Europe 2014.

Windows Server Technical Preview – Delivery of Integration Components

Those of you who have run more than one generation of Hyper-V will understand the pain of updating integration components in a VM’s guest OS. If you run Windows (this is not applicable to Linux because the process is different) the you need to run the latest ICs in a guest OS for that VM to have:

  • The latest virtualization features
  • Stability
  • Performance

We typically have seen new versions of the ICs in three occasions:

  • A hotfix or Windows Update
  • A service pack – no longer relevant but an update rollup might bring new ICs
  • A new version of Hyper-V

The process was that VMGuest.ISO was updated on the host, and we would mount that ISO from the VM to install the latest integration components. This assumed that:

· We had admin rights to the guest OS – not applicable usually in a cloud

  • Network access
  • Time
  • Patience

We had workarounds such as using PowerShell or System Center, but again, this assumed we had rights to the guest OS or network access.

Microsoft was keen to solve this issue … and they went to a method that I think many of us will approve of: updates to the Windows integration components for Hyper-V will be delivered by Windows Update (and hence WSUS). This has started with delivery to any of the following guest OSs running on the Tech Preview of vNext:

  • Windows Server 2012
  • Windows Server 2008 R2
  • Windows 8
  • Windows 7

Microsoft uses KVP (enabled by default) to determine that the VM is running on vNext.

This new process will give cloud admins control over the IC release (via WSUS) and will automate the delivery of the ICs to all guests that run Windows Update, ensuring that clients are up to date and can avail of the best that Hyper-V can offer. No more McGuyvering required.

Microsoft News – 17 December 2014

Things have settled down a little after last week’s surprise Azure announcements.

Hyper-V

Azure

Office 365

Microsoft Partners

Licensing

  • Price increases in 2015!! SPLA/hosting licensing costs are going up. Hosters will have no choice but to pass that on to their customers.

Miscellaneous

Windows Server Technical Preview – Cluster Functional Level

This feature is tied into Cluster Rolling Upgrade. When we are doing a rolling upgrade of a cluster (from WS2012 R2 to vNext), we will temporarily have a mixture of WS2012 R2 hosts and Windows Server vNext hosts. This is referred to as mixed mode.

To avoid issues, the cluster will either:

  • Run only features of the down-level hosts
  • Run features only on down-level hosts

For example, on a storage cluster (SOFS) running disk deduplication (for VDI personal VMs), the cluster will only run deduplication optimization jobs on the down-level hosts because vNext optimization will make changes that are not backwards compatible.

This mixed mode is TEMPORARY – it should not be run for months or years!!!!

EDIT: Today (17/Dec/2014) I learned that Microsoft will have a support limited of 4 weeks for running a cluster in mixed mode. They want you to finish the migration ASAP, but 4 weeks will be the support limit. There is not hard coded limit, but now you know what they’ll support.

EDIT: I also learned on 17/Dec/2014 that Microsoft will not put a limit on how long v5.0 VMs (VMs with WS2012 R2 host compatibility – more on this later) can run on a higher level cluster.

The goal is that you upgrade each node in the cluster as quickly as possible. You might pause half way through to observe the stability of your hosts (drivers, firmware and external storage/networking hardware). If you’re happy you continue the upgrade. If not, you can rebuild the upgraded hosts to WS2012 R2 and live migrated your VMs back.

Note: VMs will be manually upgraded to vNext and this is why you can live migrate VMs between WS2012 R2 and vNext hosts within the cluster without any issues.

When you have finished the upgrade you will complete the project by raising the cluster functional level. This opens up the cluster’s vNext features and then you should manually upgrade the VMs to v6.0 (vNext).

Windows Server Technical Preview – Cluster Operating System Rolling Upgrade

A big pain point with Microsoft’s increased cadence of releases of Windows Server is that upgrading a cluster has been a royal pain in the arse.

Previous to the release of WS2012 R2, there was only one process: build a new cluster (either by buying new hardware or draining a host from the old cluster) and do an out-of-band migration of VMs from the old cluster to the new one. WS2012 R2 decreased the pain slightly by allowing Cross-Version Live Migration – but we let Microsoft know that this wasn’t enough.

Windows Server vNext will allow you to perform a cluster rolling upgrade without creating a new cluster. You will be able to do this from WS2012 R2 to vNext (note I did not say WS2012 or W2008 R2 or W2008).

The process is that you will rebuild each node in the cluster, one at a time with Windows Server vNext. You will, for a short time only, have hosts running WS2012 R2 Hyper-V and vNext Hyper-V in the cluster at the same time. This is called Mixed Mode, and VMs can live migrate between the nodes. Eventually you will complete the project by raising the cluster functional level after all hosts in the cluster are on vNext.

image

The flow chart of the process is shown here:

image

This feature will be a major time and money saver, and will allow Hyper-V customers to keep up with the fast release of new versions of Windows Server Hyper-V.