If your IT department is like most others, you probably have a bunch of old servers collecting dust in the corner...
of your data center. But did you know that today's free virtualization technologies will let you turn those old hunks of junk into hosts for virtual machines (VMs)?
This article will address the pros and cons of combining older server hardware with VMware's free server virtualization product, VMware Server.
What is legacy hardware?
The first question a lot of people ask me on this subject is, "What is legacy hardware?"
Unfortunately, that question has no clear answer. Any piece of hardware more than a few years old is probably considered legacy by some standard. We work in an industry in which the majority of players build technology based on what came out a few months ago or is coming out a few months from now. The term "legacy hardware" is just an artificial construct forced into existence by the nature of external hardware and software development.
Following that logic, if an application does not demand the latest and the greatest out of its hardware, the moniker of legacy means nothing. Luckily for us penny-pinchers, VMware Server will run on just about anything, but you should be aware of some caveats before you go dusting off that old VAX.
Actually, forget the VAX and the Alpha and the Itanium. The first rule of VMware Server club is that there is no VMware Server club without x86 hardware.
Let's say you have found an old box that used to be a back-end Exchange server, and it has dual Xeon 2 GHz processors and 4 G of RAM. That's a mighty fine lookin' piece of hardware you have there partner, what kinda warranty does that thar beauty have? Two year? Three year? Five year?!?! Oh, that's right, it doesn't have a warranty anymore; it expired last year.
It is extremely important to keep in mind when dealing with older hardware that warranties may be expired. This is okay if the purpose of using the old hardware is to virtualize some development machines, but you should never run production VMs on a host server that does not have a warranty attached to it.
Technology moves fast, but aside from a gamer's video card, most computer components have a shelf life of at least a few years. Then there is the anomaly of what happened this year. Intel and AMD introduced us to dual-core processors with virtualization technology (Intel-VT and AMD-V). Most of the time, a new processor is something to consider if you are building a new machine but not an issue if you already have a perfectly good server.
With the Intel-VT and AMD-V enabled processors, you have a different story. These new processors provide hardware assistance for virtualization products. Older hardware will most certainly not have these chips in them, so do not be surprised if future versions of VMware Server require these processors and relegate that legacy hardware to the junkyard.
For the time being, all the freely available virtualization products can function with or without Intel-VT and AMD-V (the exception being Xen's virtualization of a non-paravirtualized OS such as Windows), so while the lack of this hardware assistance may not greatly affect you now, it might in the future. But by then your legacy hardware may be new enough that it includes these processor technologies.
You face one more issue with older hardware and processors -- 32-bit vs. 64-bit. When it comes to virtualization, it pays to be 64-bit. This is because VMware Server requires a 64-bit host in order to virtualize a 64-bit guest. Newer server applications such as Microsoft Exchange 12 (2007) will require a 64-bit OS once it is released. It will help to have a virtualization solution that you can test these products with, and your legacy hardware may not be up to snuff.
Like the hardware provided virtualization assistance, this may not be a big deal to you right now, and by the time that it is you may have a few extra servers laying around that are 64-bit. For now, you should be all right with 32-bit.
Gigabit network connections
There seems to still be a large number of legacy servers out there that do not have Gigabit network connections. While most single-purpose servers do not require a Gigabit adapter (some do, but most do not in my experience), a server that plays host to many VMs most likely will at one time or another saturate its bandwidth and feel the need for speed. If a server does not have a Gigabit network adapter, you may always be able to add one with a PCI card. Then again, you may not.
PCI cards are an oft-underrated part of a machine, but anyone who has built enough servers knows that choosing the right PCI configuration is important. The last few years, PCI has taken the journey from PCI, to PCI-X, and now to PCI-E (Express).
You may think that you have a spare Gigabit NIC lying around that you can throw in that old piece of hardware to bring it up to par, but then you find that your NIC is PCI-E and your target machine does not support PCI-E. While PCI mismatching is generally not that big of a deal because PCI-X is backwards compatible with PCI (it is slower of course), it is one more thing to keep in mind and on rare occasions it can halt a project.
Fibre channel cards
Another thing older servers tend not to have are fibre channel cards. Unless it was a server's previous role to be connected to a SAN, I can almost guarantee you that you did not spend the extra money for an HBA, because those things are expensive.
But even though we are not using ESX, it is still possible to store VMware Server's VMs on a SAN via the host operating system. That host OS will need to talk to the SAN, and an HBA is the fastest way to do that. As long as you have a sufficient amount of local storage to host a few VMs (30-40 G is a conservative estimate), you'll be fine.
This tip addressed a few of the sticking points that you may run into when using legacy hardware with free virtualization technology such as VMware Server. While none of these items prevent this solution, several of them do need to be kept in mind nevertheless. Now go play the good doctor F. and bring some of those old servers back to life!
About the author: Andrew Kutz is deeply embedded in the dark, dangerous world of virtualization. Andrew is an avid fan of .NET, open source, Terminal Services, coding and comics. He is a Microsoft Certified Solutions Developer (MCSD) and a SANS/GIAC Certified Windows Security Administrator (GCWN). Andrew graduated from the University of Texas at Austin with a BA in Ancient History and Classical Civilization and currently lives in Austin, TX with his wife Mandy and their two puppies, Lucy and CJ.