Needing better VM checkpoint functionality in Azure IaaS

This week I bought myself a Lenovo W541 ThinkPad with 32 GB of RAM and specced it out with more than a TB of SSD. It’s going to be my new conference lab hosting machine. The labs I need to run to demonstrate concepts at conferences seem to require more and more VMs running concurrently – meaning that the laptops I take to these conferences need more RAM and faster disks. What frustrates me though is that I wouldn’t need to cart around such a beast if Azure IaaS had better VM checkpoint functionality.

Checkpoints form an integral part of the way I work with VMs. I treat checkpoints in the same way that gamers treat save games. Checkpoints allow me to move forward and back in time when it comes to the VM’s configuration. When I’m writing a book, checkpoints allow me to store copies of the environments that I’m writing about, which can get rather complicated when I’m writing about System Center or Exchange. I can make changes and then quickly roll them back. I can be working on the VMs as they exist in the middle of Chapter 6, roll back to how they look at the start of Chapter 3, and then apply the set of checkpoints that puts them in the condition of being ready for Chapter 9.

This sort of “make a change and reload from the save if it goes badly” approach to checkpoints is pretty common for IT Pros working on their test environments. Checkpoints allow you to not just measure twice, cut once, they allow you to “un-cut” should you still have things go wrong and you have to reset things back to where you started. Almost all on-premises VM software has some form of checkpoint functionality.

Yet there is no easy way to do the same thing with VMs running in Azure. If I’ve got a group of VMs in a configuration I’m happy with and I want to change that configuration, but I also want to have the opportunity to roll back to that configuration should things go “pear shaped”. Sure, I can accomplish the goal by playing around with exports, but I can’t do the same sort of simple rollback that I could if I had the same lab of VMs running on my new laptop. On my laptop (or home Hyper-V cluster) I take a checkpoint of everything before implementing changes, and then roll back when Murphy’s Law rears its ugly head.

I know that from the “Configuration As Code” school of thought – rather than rolling back I should just redeploy my servers using a previous revision of “the Configuration”. I certainly understand this line of thought, but I’d really like to have the option of “skinning this particular cat” in a multitude of ways.

That is, I understand that the new orthodoxy is to treat servers as cattle rather than pets, but that from time to time, especially when I’m playing around, testing, and learning the best way to come up with the most desired configuration, I kinda need to treat a couple of servers as pets rather than cattle. At least where “treating them as pets” means reloading an existing “saved game” when I stuff something up or things spin horribly out of control.

It would be great to be able to do this with VMs in Azure – but until checkpoints in Azure match checkpoints in on-premises Hyper-V, I’m going to have to keep carting about that (admittedly beautiful) heavy laptop.

(and yes I realize that how I use VMs may be different to how everyone else on the planet does - but on the other hand, who would be happy in losing checkpoint functionality from Hyper-V or VMM? I can't be the only one using it)