(This post is part of a series on “Virtualization 101” — see the first post for an overall explanation of my approach in this series.)

Have you ever suffered through a long hardware migration? Or been responsible for getting budget approval to approve overtime or comp time for those doing the work? (both being painful albeit in different ways)

When I started in the IT field fresh out of college, I quickly became responsible for Netware file server migrations — the longest one started around 8 PM Friday night and we finished sometime around 1 PM the following Saturday afternoon (took a breakfast break with my coworker at IHOP around 8 AM and then kept going). While Novell provided a great tool for this (some fond late-night memories of the erratic progress bars in Migration Wizard), we devoted serious time each year to simply refreshing hardware and all the work associated with that. We were fortunate in that for many servers we could budget for a 3 year hardware refresh cycle….but the downside was time (it was worth it though…keeping hardware longer definitely did lead to failures previously…3 years became a happy medium for refreshes).

What’s more, our preferred server vendor was HP for quite a long time — until HP bought Compaq and promptly discontinued the NetServer line we’d been using. We eventually migrated over to IBM Intel hardware (which worked well) but that brought a whole new learning curve around drivers and hardware quirks. This isn’t exactly something unique to Netware either…almost all shops dealt with this to varying degrees.

Now imagine, what if we insert a virtualization layer that provides “virtual hardware”? Windows/Netware/Linux are no longer bound directly to physical hardware when it comes to drivers. This means that when we want to swap out the underlying physical hardware the virtual machines don’t know the difference (we’ll address downtime for the swapping process later). In fact, we could even have a mix of physical server vendors providing the virtualized environment (very enticing if you decide to change hardware platforms to something new and compelling like Cisco UCS). Further, imagine that you can run multiple “virtual servers” on each piece of physical hardware — you now can leverage this capability even further.

This doesn’t diminish the need for OS-driven refreshes (aka Windows 2003 –> Windows 2008) of course. BUT…goodbye hardware refresh and all the associated time.

Simply put, this is what we did — over time we migrated Netware servers to virtual machines as their hardware came up for refresh. Once migrated, they ran as VM’s forever across multiple underlying hardware iterations. Ironically, with Netware this also solved a very important hardware compatibility question — driver support for Netware on newer hardware started to diminish. Right now, VMware is probably the most supported way to run Netware. And while we all like to think we can keep our OS installs up to date, this applies just as well to other older or not as common OSes (i.e. Windows NT 4/2000/etc.).

What is this one piece alone worth to your business? What can your IT department do with the time they’re not spending doing hardware-driven refreshes? (Hint: something strategic to the business preferably.)

Side-note: don’t worry….there’s no question storage virtualization and centralization are critical here as well….we’ll get to that in future posts.