Virtualizing SharePoint

Virtualization is not the new kid on the block anymore. Almost all businesses with the need for more than a couple of servers are at least developing a virtualization strategy and most have started thinking about about ways to virtualize a couple of their employees. Luckily SharePoint is an almost ideal candidate for virtual hardware as long as you keep just a few things in mind.

Virtual hardware doesn’t mean requirements magically become recommendations.

My wife and I went on vacation last year and rented a car that had one of those gauges that tell you how many miles you get to the gallon. My normally lead-footed bride suddenly became an eco-champion driver. Our 0 to 60 times where being measured in minutes instead of seconds, but at some moments we were getting 75 miles to the gallon and my wife was enjoying every agonizingly slow second of it. The same thing happens to a lot of people when they start boiling their servers down to a pool of VMs. Performance takes back seat to the thrill of shaving off a gigabyte here and a processor core there. Suddenly your company is running on the computational equivalent of a closest full of 5 year old desktop workstations and you are actually happy about it.

Stop the madness. Microsoft has provided hardware and software requirements, not because they guarantee the best SharePoint experience possible, but because if you don’t come close to those specifications you make them and their products look bad. In the end that makes you unhappy and it makes SharePoint look bad in your organization. Microsoft’s requirements aren’t laws, but they are a good starting point. Cutting them in half will only give you a moment of joy when you squeeze SharePoint into a tiny virtual box. That flash of fun will be followed by a lot of waiting and confusion for the rest of your SharePoint journey, because…

SharePoint wants to please you, even if it has to lie to do it.

I have gone through my preachy spiel above dozens of times with customers and about a third of the time they listen patiently then tell me; “We already set up a test SharePoint farm with less than the recommended specs, but when you look at the virtual management console it never even gets close to maxing out the processor or memory we gave it and you are telling me it needs more?” Yes, yes I am, because SharePoint is perhaps the most polite of all Microsoft products when it comes to resources; attempting do its best to live with whatever you give it. When starved for resources some applications will grab all unattended RAM refusing to release it under any circumstances just in case it might need it in the future. SharePoint on other hand will always try and leave some memory open for everyone and when it absolutely can’t get by with the resources available, it just stops doing some things. Things like completing that database upgrade you requested, or like running timer jobs, or in co-operation with IIS, caching pages so that it doesn’t take 45 seconds for each page to load. SharePoint doesn’t complain a lot about missing resources, it just does what it can and forgets the rest. Unless you look closely at the logs you might not even notice some of the things that are being skipped. I have seen SharePoint running on a virtual with 2GB of RAM, only 1.5 where in use. The customer asked if I had any idea why their system was so slow.

The moral of the story is, get close to the requirements. A 60GB c: drive instead of 80? OK. 6GB of RAM in a test server? Fine. However, cutting all the requirements in half doesn’t make sense on real hardware, so don’t expect it to work better in a virtual. While we are talking numbers though, let’s discuss your virtual host.

8+8 does not equal 12.

There is another numbers game that virtualization sometimes creates. You probably already know the term for this game, over-commitment. The details vary depending on what virtualization products you use, but many virtual hosts will allow you to create servers that strictly speaking shouldn’t “fit” on a single host server. If you total up the amount of RAM or CPUs used by all your guest machines they exceed the total amount available on the host, but somehow things magically work. Mostly. Over-commitment is a valid strategy and is one of the things that drives the economic benefits of virtualization in the first place. Like most things, a little can be good, too much can be bad, and the line isn’t always clear. I am not going to be completely naive here and tell you to never over-commit a host that has SharePoint on it. The economics of virtualization sometimes don’t allow that luxury. I am going to remind you of SharePoint’s sometimes over polite nature. If you are seeing unexplainable performance issue, take a look at both the SharePoint logs and server applications logs for signs of distress as well as the host’s monitoring tools. VMware has published a whitepaper of best practices for virtualizing SharePoint 2010 using their products. At 50 pages you may see that developing a successful strategy for virtualizing SharePoint might not be as easy as it seems at first. VMWare’s examples show a number of configurations that work and only by really diving into the numbers can you see how they might work better with some tweaking. SharePoint won’t give you a clear indication that you have pushed it too far.

So enough about polite and co-operative SharePoint, let’s talk about the other key member of your SharePoint farm, Microsoft SQL.

SQL is not SharePoint.

SharePoint might be the shy orphan in a Charles Dicken’s novel asking for another bowl of gruel. Microsoft SQL is more like a rampaging Viking raiding the server for any resources it can find. This is a big clue about how you might want to approach virtualizing your database server. If you want to figure out the best strategy for allocating resources to SQL in a virtual environment just remember how it works. Microsoft SQL is built for two purposes, executing transactions quickly, and executing transactions accurately. Anything that distracts it from those two goals is bad for performance, and database performance is a very large part of SharePoint performance. Anytime you create a situation where SQL has to request or wait on resources you create the opportunity for something to not work correctly. That is why SQL collects all the available RAM in a server even when it’s not loaded with work. By collecting resources prior to needing them Microsoft is ensuring that your database information is ready to move as soon as a request arrives. Treat SQL like an angry Viking. If you tell the Viking you are giving him 16GB of RAM, make sure there are 16GB of RAM in the bag. The same goes with persistent storage on a hard drive or SAN. You do not want the Viking to be looking at you angrily as you feverishly try to clear enough space for him to store his latest acquisition. In the world of busy database servers, microseconds are important and waiting for the virtual host to reallocate resources is not something that SQL is built to expect. Thin provisioned drives (telling the server it has a 250GB drive when it is really a 100GB file that “grows on demand”) and over-commited hosts are not things that mix well with a product that was designed to take complete charge of all the resources available to it. Give Microsoft SQL exactly the resources that you promise to it and you will avoid a lot of troubleshooting and head scratching. If you aren’t prepared to do that, maybe real hardware is your best bet for SQL right now.

This post is a little longer than I thought it would be at first, but I hope it helps to get you thinking about your SharePoint virtualization strategy. Virtual servers are here to stay and that is a good thing if we use them properly. It is just important to get past the hype and excitement of getting more for less and focus on knowing what you really need to get the best out of your technology.

Blog at

Up ↑