"We have to many servers", one of my admins grumbled to me. It was true. Our server room was overflowing. We had an individual server dedicated to nearly every function that was performed within our company. Not only that, but we had a number of older 7U servers, that were low powered by today's standards, but were still being used for many critical functions.
After much discussion, it was decided that a server consolidation effort was going to be required. While there were many functions that could be moved from slower individual servers, to a few newer, more powerful servers that would not be enough. Due to the fact that many people through out our company were used to having "their own" server resistance was high for change. We needed a way to allow people to continue to have "their server" while drastically reducing our server count. The best way to accomplish this it seemed was with server virtualization.
There are several server virtualization packages available. QEMU, VMWare, XEN, and Microsoft Virtual Server R2 seemed to be the leading players. While looking at available packages VMWare was ruled out to the excessive cost. This has since changed with the beta release of VMWare server, but this was not available at the time. QEMU was ruled out due to many in our IT staff having heard of it being slower than the other virtualization engines, so it came down to XEN and Microsoft Virtual Server R2. Cost was negligible between the open source XEN and the Microsoft product, as Microsoft Virtual Server Enterprise edition was only priced at a couple of hundred dollars, well within our range of affordability (it has since become free). We decided to use the Microsoft solution owing largely to the fact that the R2 release of Virtual Server supported fault tolerant clustering using Microsoft clustering. Microsoft clustering is something our IT staff has a large amount of experience with, and our user base has come to expect the high levels of availability it affords us.
Putting Virtual Server R2 to the Test
The initial install of Microsoft Virtual Server R2 was extremely simple. Installing a virtual server was almost as easy as that. Microsoft has done a good job in making this process as painless as possible. We ran up several test servers in our development environment, and began to play with the product. We were impressed by the speed of the virtual servers, the ease of "upgrading" components such as adding RAM or network adapters to the virtualized system, and the ease of migrating virtualized systems from one virtual server host server to another. Unfortunately, not all was smooth sailing. The fail over clustering support, while functional, is rather cumbersome and time consuming to configure (you can download the clustering document here). Also, the P2V (physical to virtual) migration tools were also very difficult to use, and required the use of another Microsoft Automated Deployment Services; a product that we did not have deployed. You can view an image gallery of virtual server here.
Right Tool for the Job?
We have been very happy with Microsoft Virtual Server R2. While the road has not always been the easiest, due to the current state of clustering and P2V migration, we have been extremely happy with the product. Currently we have 15 virtual system deployed into production among 2 virtual server hosts. We run a variety of services from these boxes, including our Exchange Front End server, our accounting and payroll servers, and our SharePoint Services environment. Users for the most part have not even noticed the changeover from physical to virtual, though there have been some complements about faster performance on some of the servers. This is due to the hard drives of the virtual systems being on high performance SAN storage, and the host servers being much faster than their previous physical servers. This consolidation has reduced a total of 42U worth of rack space down into 8U, this is a huge saving in our cramped data center. Microsoft Virtual Server R2 has definitely been the Right Tool for the Job!