Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
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.
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.
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
Now that the final Hyper-V virtualization bits for Windows Server 2008 are available people have started
With the announcement of the release of the new Microsoft Hyper-V virtualization technology, I've
I have been running TFS in VMWare as a single server deployment for around 8 months now with no problems :)
Yes, Includung SQL Server 2005
Hi!
Just installed TFS on Hyper-V last week. We are a small development team and so long everything works very well.
/Mattias
The Accentient Blog on Electronic Scrum Boards Grant Holliday post a whole bunch of stuff. Eugene Zakeharyev...
こんにちは。本日は、ブログ記事のご紹介です。何度かご紹介しています bharry's WebLog (VSTS のテクニカルフェローの Brian Harry のブログ)にて Hyper-V 上での TFS
What does the road map look like for testing this on VMWare server. The organization that I work with has made a huge investment in this area and are more and more requiring that machines be VMWare. Do you plan on supporting this configuration and if so, when do you plan to do so?
We have no plans to specifically test TFS on VMWare. VMWare, I believe, is participating in the Windows virtualization certification program, at which point they will get "official support" for all Microsoft products.
We have a team of modest size and a code base (artifact base?) of intermediate size. Running both tiers in a two-CPU VMware VM has been almost entirely painless for a year now.
We did have an anomaly that wiped out the security settings and I still haven't gotten reporting services to work again. That's meant I can't create new "team" projects but it hasn't been a big deal so far. Oh, and I wasn't able to move the data when I went from a TFS2005WGE pilot server to the current TFS2008RTM production server: I had to check in a series of snapshots to reproduce the skeleton of the pilot server's revision history.
Anyway, there's no noticable speed issue for tens of thousands of files and tens of developers. The VM lives on a nice beefy eight-core server with a carefully tuned RAID and the VM's disk is a native parition in the RAID. Your mileage may vary but I'm pretty sure the tuning is overkill for our scale of operations.
TFS in a VM beats VSS on a dedicated server by at least 3-to-one on "get everything" and is orders of magnitidue faster for certain operations that I do frequently -- like subtree history.
My conclusion is that TFS is so "performant" that you don't need to think about it unless your workload is so large that a share on a fast fileserver would be too slow.
For what it's worth, I chose RAID 10 for our server. I wanted it optimized for read bandwidth for large(ish) files rather than the transaction processing workload more typically seen in RAID selection and tuning scenarios. I'm happy with that choice but we cheaped out on the raid controller and it doesn't support virtual volumes on "composite" RAID levels. Live and learn.
-swn
One of the topics that’s come up a few times recently while talking to TFS users has been Hyper-V. Specifically,
Brian,
It may be helpful to put a similar post out again regarding TFS VS 11, and any new information to consider, performance issues that have changed, or even just to let this bit of information be known about for VS 11 searches.
Is it safe or advisable to put the Sharepoint layer on one VM, the app tier on another?
Does the newer version of Sharepoint in VS 11 make any difference in this equation?
Is it still not adviseable to have the DB Tier on a VM?
Doesn't having the App Tier on VM have some really great advantages for backing up, scaling, etc. that may be worth talking about?