So Many Questions. So Little Time (part 1)

It’s another snowy day up here in Minneapolis, but earlier this week I had the pleasure of traveling down to tropical Kansas City.  Overland Park, KS, to be more specific.  And on that particular day we decided to try something new.  We (John Weston and I) asked our attendees to write down questions, topic areas, off-hand remarks, and comments on slips of paper during the event.  What we wanted to do was help facilitate some more discussion during our IT Camp.

“IT Camp? What’s that?”

An IT Camp is like a TechNet Event without (or with minimal) PowerPoint.  It’s more of a discussion than a presentation.  It’s interactive, loose, and fun.  We have some topics to discuss and certainly some information to disseminate, but we want the conversation to be driven mainly by the audience. 

Anyway.. the reward for good questions was a T-Shirt.  And the result of this ask of our guests was phenomenal.  I have sitting here on my desk a pretty nice stack of questions; most of which we were able to answer during the event, but some we didn’t have time to get to. 

So what I want to do is to put the questions up here on my blog (the ones I can read, anyway.. some of you folks should have been Doctors, because I can’t read your writing!), and then I’ll summarize the answer that we gave, or make up (?!) a new one for you here. 

Disclaimer: I will provide links to additional information and the sources of my answers, but some of my answers will be opinions and speculation. This is a blog – not a knowledgebase article. You have been warned.

---

Here we go with question #1…

“Given that differencing disks enable multiple instances of a running OS from a single OS image, please discuss and outline an appropriate best practice patch management strategy.” -David U.

First of all, for those of you who may not be familiar with the concept of a differencing disk… Differencing disks are virtual hard disk (.VHD) files that link from child, to parent, to grandparent.  The idea is that you can create an install of an OS as a virtual machine.. and then use that .VHD hard disk installed OS to be the basis for one or more child disks.  The children start from that point, and their parent disk is never ever modified.  (It can’t be, because doing so would break the children.)  You can do this process of linking down many levels if you choose.  Even though some content of the parent disks are being read as a part of the disks that are in use or running operating systems, all changes are happening in the children at the end of the hierarchy. 

For a more complete description of differencing disks, CLICK HERE.

To answer your question, I first need to go back to what I said: the parent disk is never ever modified.  This implies that all patching and updates can only happen on the last child in the chain, so updates will always be applied there.

So.. a big benefit of differencing disks is in having a common, pre-installed operating system starting point for many running machines that can be created quickly.  And the amount of disk space saved initially is enormous, because many machines are sharing a common set of bits for their running installations, while the differencing disk starts out very small and only grows when there are changes.

But the downside (besides a slight degradation of performance) is that, eventually, through the natural changes and updates that occur, the differencing (child) disks will be as big or bigger than the parent disk it’s linked to.

So how does one approach patch management?  

You need to (for now, at least) get beyond the desire to patch the parent disk.  It’s not possible.  It may be someday**, but not at this time.  So with that in mind, your best practices around patch management really can’t consider the fact that these machines are running off of a common parent disk; other than the fact that eventually you might want to create a new starting-point, fully patched OS disk to build new children from. 

**I say this only because it seems like a good idea to add as a feature in the future. I have no knowledge whatsoever on whether this is being planned or created.

My recommendations:

In a lab environment, it’s a great tool for quickly rolling out new machines.  Eventually (maybe before every major re-build or re-think or new project) you may want to create a new machine off of the old parent, apply updates, shut ‘er down, and then consolidate the changes into one new parent disk.  (for instructions on how to merge a child differencing disk with its parent, CLICK HERE) 

For production use, however, the limitations long-term out-weigh the benefits.  For the sake of performance and simplicity, and even for reducing storage requirements longer-term, I suggest that you don’t use differencing disks for production workloads.  Treat your production virtual machines as you would any other physical machine; which includes your patch management practices.