Hyper-V and TFS

One of the topics that’s come up a few times recently while talking to TFS users has been Hyper-V. Specifically, we often hear:

1. What hardware & software setup should we use?

2. What type of fail-over options should we use?

3. What type of redundancy should we use?

In this post, I will attempt to answer these three questions. If you have any other questions or wish for some further clarification, feel free to put it in the response.

What hardware & software should we use?

First, it is important to note that the only version of TFS that officially supports Hyper-V is TFS 2008 SP1. You can find information about creating a "Slipstream" install in the installation guide (located here https://www.microsoft.com/downloads/details.aspx?familyid=ff12844f-398c-4fe9-8b0d-9e84181d9923&displaylang=en ) under the title "How to: Integrate the Installation of Team Foundation Server and Service Pack 1."

Second, SQL only supports Hyper-V under certain configurations. The current configurations are discussed here: https://support.microsoft.com/?id=956893. If you want virtualize your data tier, make sure you give it a dedicated harddrive.

Third, if you want to set up SQL 2008 using Hyper-V you should make sure to read & follow the whitepaper posted at: https://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx.

Fourth, Chuck Sterling has a great post on his site for improving the performance of TFS on a virtual machine: https://blogs.msdn.com/charles_sterling/archive/2006/11/22/how-to-boost-tfs-performance-under-a-vm-by-dugie.aspx As for hardware, Brian Harry made a blog post last summer on this issue in which he answers the hardware question at length.: https://blogs.msdn.com/bharry/archive/2008/06/27/tfs-on-hyper-v.aspx.

What type of fail-over option should we use?

As for a fail-over strategy, there Hyper-V presents the additional option of backing up Hyper-V images. This approach has the advantage that when your system goes down, you can quickly bringing up an old image without having to reinstall all of the old components. You can find some documentation about setting up Hyper-V and Fail over here: https://technet.microsoft.com/en-us/library/cc732181.aspx.

The other failover option is the standard backup your SQL databases. If you backup your SQL databases, you’ll probably get better granularity since SQL backups are more established. (Also, with SQL backups, you are only backing up SQL databases, whereas with a full snapshot backup, you are backing up the entire system.) You can find the information about setting up SQL backups in TFS here: https://msdn.microsoft.com/en-us/library/ms253070.aspx. The disadvantage of this approach is that if your application-tier goes down, then you’ll need to reinstall the OS, SQL,TFS, etc… As a result, you may have larger down time.

These two approaches aren’t mutually exclusive. You could, for example, backup the Hyper-V weekly and backup the SQL database nightly, while using SQL log shipping to backup incremental changes every 15 mins. This could be overkill, depending on your scenario. Regardless, whatever strategy you use, you should regularly try dry-runs. So, it may not be a bad idea to try running through the recovery scenarios for both approaches and choosing which you prefer.

What type of redundancy should we use?

Finally, for redundancy, there is one difference for redundancy between a Hyper-V system and a physical system, and that is you want to make sure not to put all of your Hyper-Vs in one (hardware) basket. Especially, I’d make sure to keep the backups on a separate physical device. Also, if you have Hyper-V backups and SQL backups, I’d keep those on separate physical devices as well.

I hope this discussion helps. If you have any more questions, feel free to ask

--Aaron