Today, I saw a nice report from one of our MVPs about their experience updating their production TFS server to the TFS 2010 RC: http://blog.hinshelwood.com/archive/2010/02/10/upgrading-from-tfs-2010-beta-2-to-tfs-2010-rc.aspx
I wanted to share it for a couple of reasons.
First, it’s nice to see that they’ve been successful and he documents his process and give some advice.
Second, he make a comment about Hyper-V snapshots I wanted to talk about. A few months ago, it came to my attention that Microsoft won’t support many scenarios where you’ve restored a system (particularly a server) to a saved snapshot. The context in which it crossed my consciousness was that SQL Server is not supported (and therefore TFS). At first blush I was shocked and immediately started to look into it.
What I discovered is that the real issue is taking a snapshot of a running system – not of a shutdown system. When a snapshot is taken of a running system, it is taken exactly as is: network connections open, interrupt requests in progress, everything. Of course, restoring a snapshot doesn’t restore anything outside the context of the current machine (other servers you are connected to like attached databases, mirrors, web services, etc). It also can’t restore the hardware back to its precise state.
As such when a snapshot is restored, it’s a bit like getting abruptly awakened from a deep sleep. The system has to try to make sense of how it’s internal state relates to the external state. The OS has been hardened to handle this pretty well but many, dare I say most, applications do not. And quite honestly, I’m not sure they every will because for many applications it is impractical or impossible.
So my VERY STRONG advice to you is shut down your Hyper-V server before you take a snapshot if you hope to ever restore it. It might work 500 times for you and then on the 501st time boom – your snapshot of a running system won’t restore to a consistent state and you are hosed.