With the announcement of the release of the new Microsoft Hyper-V virtualization technology, I've seen a surge of questions about TFS support for Hyper-V.  We have tested TFS running in a Hyper-V virtual machine.  It works well and is officially supported.

TFS Components & Support

One thing to keep in mind is that there are 2 major components of a TFS server.  The first is the TFS application tier.  It runs fine in Hyper-V, Virtual Server and VMWare.  You must remember that the TFS application tier in TFS 2005 and TFS 2008 is 32-bit only - so, if you are going to use it on a 64-bit Win2008 machine running Hyper-V, for example, you will need to run a 32-bit OS in its VM.  Our support team will work with you on support issues regardless of which virtualization technology you use.  However, we may ask you to reproduce problems outside of the virtual environment if we suspect it is causing a problem.  The exception to this is Hyper-V.  With Hyper-V, we are introducing full support on the virtual environment.  We (Microsoft) are also working on a certification program so that all virtualization technologies that meet the requirements can achieve the same level of support.

The second major component of a TFS server is the data tier.  The data tier is a SQLServer and the only TFS code that runs on it is TSQL stored procedures.  Of course, in a single server TFS install the application tier and the data tier run on the same machine.  My understanding is that SQL server 2005 and before do not officially support any virtualization technology.  SQL is introducing virtualization support with SQL 2008.  If you are going to use TFS with SQLServer 2008, make sure you use TFS 2008 SP1 (to be released this summer).  In general, my advice to TFS customers has been that it's fine to run the TFS application tier in a 32-bit VM but always run the SQLServer on native hardware (preferably on 64-bit if you need the system to scale).  One reason for this is for performance (see more below).  Another reason is that I have seen one or two instances of data corruption problems with SQLServer running in an improperly configured VM - the one that comes to mind was a customer who was running SQLServer in a VMWare VM and had delayed I/O enabled in the VM.  Delayed I/O is not something you want at all on a SQLServer machine - it violates key guarantees that SQL relies on to guarantee data durability.

Virtual Machine Performance Guidance

I often get asked about recommendations about hardware configuration for virtualization.  I generally focus on 2 things: memory and disk I/O.  The memory recommendation is pretty easy.  If you want to run TFS in a VM, remember that there is also a host OS running.  Sum up the memory requirements of every app in every VM you are running on the system and add about 1GB for the host OS.  I've generally found that algorithm to work well for people and I expect it will work well for Hyper-V as well.

The more complicated one is I/O.  One of the historical problems with virtualization technology is that it adds overhead when virtualizing I/O (in this case I'm mostly concerned about disk I/O).  A high scale TFS server performs a ton of I/O and any overhead can be a problem.  Fortunately, disk I/O on the application tier is generally not too high (except in the most high scale systems).  The only major source of I/O is a file cache that reduces the load on the SQLServer for commonly requested files.  TFS's use of SQLServer, however, can be very I/O intensive.  My advice to anyone running any I/O intensive application in a VM is to make sure you have a high performance disk subsystem.  Error on the side of extra disk performance.  For example, use 10K RPM or better drives, consider using RAID 10 that enables more concurrent I/O.  Make sure you have a good disk controller card.  If your system is particularly high scale, consider using a high performance SAN.

Some of this guidance may change over time with Hyper-V.  Hyper-V is a very efficient virtualization technology but I don't have enough experience with it yet to say for sure how it will affect these recommendations.  As I learn more I'll keep you up to date.

Good luck and let me know if you have good or bad experiences with TFS and Hyper-V.

Brian