Production Checkpoints in Windows Server 2016

We’ve  had snapshots, or better checkpoints as we call the now for consistency amongst products, for a longest time in Hyper-V. I have always liked and used them to my benefit. That’s what they are intended for. But you have to use them correctly, in a supported and smart manner. Some (or perhaps not an insignificant number of) people did not read the manual and/or do not test their assumptions before trying something in production. Some times that leads to a lesson, sometimes it leads to tears.

We now have the choice between two type of checkpoints: Production Checkpoints and Standard Checkpoints.

A standard virtual machine checkpoint all the memory state of running applications get stored and when you apply the checkpoint it’s back magically. Doing this to a production SQL or Exchange Server for example causes (huge) problems. With some applications these problems are minor or transient but it’s not a healthy consistent state to be in, and recovery has to happen. Which could  happen automatically or require disaster recovery depending on the situation at hand.

Production checkpoints are made in application consistent manner. For this the leverage Volume Shadow Copy Services (or File System Freeze on Linux) which puts the virtual machines into a safe state to create a checkpoint that can be restored like a VSS based, application consistent backup or SAN snapshot. This does mean that applying a production checkpoint requires the restored virtual machine to boot from an off line state, just like with a restored backup.

The choice for what type of checkpoint can be made on a per virtual machine basis which make it’s flexible as you can pick the best option for a particular virtual machine for a specific purpose. As you might have guessed, that still requires some insight, reading the manual and testing your assumptions. But you now can have the behavior you want and way to many assumed to have.


We also have the option of allowing or disallowing for a standard checkpoint to me made if for any reason (which results in the VSS snapshot in Windows or file systems freeze in Linux  in the guest might not work or are not available) a production checkpoint cannot be made. Here’s the table of what type of checkpoint can be used when from MSDN. I conclude that the chosen default is the best fitting one for most scenarios.


You also have the option of choosing the standard checkpoints for a virtual machine. That gives you the exact behavior as with all previous versions of Hyper-V.

I love the GUI for ad hoc work but when I need to do this on dozens or hundreds of virtual machines or potentially tens of thousands when running a larger private cloud this is not the way to go. PowerShell is you long time trusted friend here!


As you can see just the “-CheckpointType” parameter you control the check pointing behavior. And as it is very easy to grab all virtual machines on a host or cluster setting this for all or a selection of your virtual machines is easy and fast. Let’s set it to “ProductionOnly” and grab the setting for that VM via PowerShell


When you create a checkpoint of a Windows Server 2016 Hyper-V host you’ll even get a nice notification (you can turn it off) by default that the Production checkpoint used backup technology in the guest operating system.


It’s also important to realize that this capability is the basis of the new checkpoint based way of making backups in Windows Server 2016 as well. But that’s a subject for another blog post. Thank you for reading!

RemoteFX and vGPU Improvements in Windows Server 2016 Hyper-V

Let’s take a look at some of the RemoteFX and vGPU Improvements in Windows Server 2016 Hyper-V. For me the abilities they are adding in this release are significant and a break through. Why? They are talking away many of the last show stoppers for a number of scenarios that are important to the ecosystems I roam around in, when the CxO have a clue that is.

What are we looking at that’s new for Windows Server 2016?

The things that are breaking down the biggest showstoppers are:

  • OpenGL & OpenCL API Support (FINALLY!)
  • 1GB dedicated VRAM
  • 4K Resolution
  • Serverv VM Suppport (very important in our GIS environment actually) Generation 2 VM Support (YES!)
  • Improved performance
  • H.264/AVC codec investment

Now, I missed this initially but it was announced at Microsoft Ignite 2015 that RemoteFX will support generation 2 virtual machines and it allows us to still benefit form the future of virtual machines without losing RemoteFX. Until now generation 2 virtual machines were no compatible with RemoteFX.This was due to the Generation 2 virtual machines not having an emulated PCI bus, which RemoteFX needs until WIndows Server 2012 R2 and Windows 8.1.

Generation 2 support combined with Server support in the virtual machine and OpenGL (ip to 4.4) /OpenCL (up to 1.1)  is a breakthrough, let’s hope the versions supported don’t spoil the party. I wonder if they can come up with a mechanism to upgrade support if OpenGL for newer versions that are released. But application compatibility was very limiting.

This is really great news and will make Hyper-V a far better candidate for many more scenarios than ever before.

Get your test rig set up

So it’s time to upgrade the lab server with a RemoteFX capable GPU to Windows Server 2016 TPv3 and test this.

I think some of our GIS engineers will be very happy with these new capabilities for ESRI Arc GIS, Adobe, AutoCAD, … and many more less well know specialty software they need.

If you want to test it out here’s the Experience guide for Enabling OpenGL Support for vGPU in Server 2016

So we set it all up but unfortunately there is still an issue being worked out at the moment of writing.


But I will help you get started for when it’s fixed.  Which I hope will be soon! To me it looks like they “just forgot” to activate RemoteFX for server as it look a lot like a Windows Server 2012 R2 VM where one tries to add a RemoteFX card, it just doesn’t work. Sale host with Windows 10 Enterprise does not have this issue …



So why not test with Windows 10? Well the OpenGL/CL capabilities are server only. And those are important to us!

Putting Windows Server 2016 TPv3 To The Test

I’ve dedicated some time to start investigating the new and improved feature and capabilities ever since Technical Preview 1 (TPv1). We kept going with TPv2 and now TPV3. The proving grounds for putting Windows Server 2016 TPv3 to the test are up and running.image

As usual I’ll be sharing some of the results and finding.  I only use the public Technical Previews for this so this means that it’s public information you can read about and go test  or find out about yourself.

So far things are going quite well. I’m learing a lot. Sure, I’m also hitting some issues left and right but on the whole Windows Server 2016 is giving me good vibes.

Expertise, insights, knowledge and experience is hard won. It’s never free. So I test what I need to find out about, find interesting or think what will be valuable in the future. Asking for me to go and test things for you on demand isn’t really going to work. I have bills to pay and cannot spend time, effort & resources on all of the numerous roles and features available to us in this release. Trust me I get enough offer to work for free or peanuts from both strangers and employers, so, thanks for the offers but I need no more 😉

Lightning Fast Fixed VHDX File Creation Speed With ReFS on Windows Server 2016

In this blog post we’re going to take a quick look at the lightning fast fixed VHDX file creation speed with ReFS on Windows Server 2016. We’ll compare it to creating fixed VHDX files On NTFS with a SAN that supports ODX. Both the NTFS and the CSV volume are CSV disk in a Hyper-V cluster and the test is run on the same node. The ODX cabale SAN is a Dell Compellent with Storage Center 6.5.20.

We create on  a selection of fixed VHDX files sizes (50GB, 100GB, 500GB and 1TB) on NTFS volume Windows Server 2016 host You can see the quite excellent results in file creation speeds with ODX.


These results are very good (DELL Compellent always did a great job implementing ODX) and the time to create a 1TB fixed VHDX is just over 5 seconds consistently. Impressive by any standard I would say! When we start using CSVs we can see that times double for the larger VHDX sizes but still +/- 12seconds for a 1TB disk is impressive by any standard. There is little difference whether the node where the script runs owns the CSV or not.



Can things be more impressive? Let’s do the same exercise on a ReFS volume on a Windows Server 2016 host. Same server, same SAN with ODX enabled but note that ReFS does not even support ODX, so it cannot be leveraged.


No matter what the file size of our fixed VHDX files they are created in just over 1 second consistently. This is very impressive.


When we use a CVS LUN we still see the same impressive results. On CSV LUNS not owned by the node where we execute the test script we see a creation time of 2 seconds for VHDX sizes of 1TB. Still lightning fast.

If you do not have a SAN that supports ODX you can see why ReFS might become a very attractive choice for the file system for your Hyper-V virtual machine data volumes in Windows Server 2016. I can see why they mentioned it as the preferred option for Storage Spaces Direct. Do note that ReFS does not support deduplication and/or UNMAP (I see no dedupe support yet for virtual server workloads on the horizon either yet?). If you move large amounts of data around ODX does provide significant assistance with this. So with ReFS go for a large SSD tier. Flash only without deduplication or erasure coding might be cost prohibitive I’m afraid.

But let this not put you off ReFS. It has many benefits in combination with storage spaces and these new VHDX operation capabilities just add to that. So for many environments with commodity based storage this has become an even more interesting choice.