If the computer industry were an old-time medicine show, virtualization products would be among the top-pitched curealls. Unlike snake-oil, though, virtualization has plenty of evidence attesting to its usefulness in server consolidation, disaster recovery, interoperability support, software testing, and even running production applications. Virtualization supports all these IT areas at Hobsons, a provider of Web-based software modules that help higher-education institutions manage their enrollment. Patrick McFadin, Hobsons’ director of engineering, credits Hobsons’ virtualization successes to a sensible approach to implementing the technology. Here, Patrick discusses why implementing virtualization made business sense for Hobsons and lessons he’s learned in the process.

Q: Give a thumbnail of the IT environment you’re supporting. What parts of this environment did you want to virtualize, and why?

A: Our environment is a mixture of Windows and UNIX. Our flagship application \[Hobsons EMT Connect\] is built on Microsoft .NET Framework, so it’s running on Microsoft IIS, and the back end runs in Oracle. We run all our DNS on UNIX and batch jobs on Windows, and we tie the whole thing together with Active Directory.

We have four data centers. About a year ago, we needed more rack space in those facilities. We were already using VMware for desktop virtualization, and \[server virtualization\] seemed like a natural extension of that.

As a first step, we planned to move our entire QA and testing and release candidates into an all-virtualized environment. At that time, we were getting ready to move into another rack because we were out of power. I actually had a contract on my desk for a new rack. Instead, we started decommissioning machines and virtualizing them, and I canceled the contract. That would have been $2,000, just to get the new rack installed.

Q: How many servers did you eliminate because of virtualization?

A: We went from a rack full of machines down to two. But they’re big, beefy machines.

Q: How many virtual machines (VMs) are on your servers now, and what applications are running on them?

A: We’re running about 20 VMs now, for testing, QA, development, and production applications. Our DNS servers are running on \[VMs\], as are our source-control system, a Web server that our salespeople use, and some of our internal applications, such as reporting.

Q: How did you evaluate virtualization products?

A: We looked at the major players. For us, the Microsoft \[virtualization product\] was off the table because it was a single-server option. Also, we’d had issues with some of the earlier versions of the \[Microsoft virtualization product\] when we needed to reboot all the VMs after patching the underlying OS. Our environment needs to be up almost 24 × 7; we can’t have servers going down.

We needed a multinode environment with transparency between the nodes, to support 64-bit Linux and Windows, and really good performance—\[a product that provided\] acceleration behind the scenes. VMware was an obvious player, but we had some troubles with their hardware compatibility list—and the price!

Finally, we looked at Virtual Iron, which was fairly new in the market. We tested the product on a couple machines and saw that it did everything we wanted. For instance, you could move VMs around from hardware node to hardware node. And because Virtual Iron uses a hypervisor, there’s no base OS to patch. It also provides failover \[between VMs\] and accelerating drivers that go onto the base OS. In testing, we found that the performance of the VMs was pretty good. That was a big selling point, as was the price.

Q: Was your plan all along to try out virtualization for development and testing and eventually migrate your production applications?

A: Our plan was to put our QA on VMs first and test it there. \[We reasoned that\] if the virtualization was going to break, it would have a lower impact on our business at that point.

Q: What are some virtualization lessons you’ve learned?

A: Understand the scope of what you’re trying to do before you move applications to VMs. It’s so easy to add VMs that you can overvirtualize really quickly. Have a tangible project plan for virtualization.

We also learned some of virtualization’s little pitfalls. For instance, it’s easy to lose track of where a VM is. You forget that you have to manage your infrastructure. And it’s so easy to bring a VM online that you might get a little lazy about security. \[When you bring up a VM\], just as when you rack up a server, you need to treat the virtual network interfaces \[like physical ones\] and make sure that you do your firewall, port scans, and other security and patching procedures.