Down the virtual rabbit hole

Virtualization is designed to render differences between systems irrelevant, but this is a good-news/bad-news arrangement. The good news is that IT can treat every server as an x86, with all x86 systems being standard. The bad news relates to the new difficulties we face in diagnosing and treating serious, but nonfatal illness when virtualization covers the source of the problem.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Virtual machine managers and tools do an ideal job of notifying administrators of both catastrophic failures and the self -- healing steps the VMMs take in response to issues such as resource shortages. But as I keep warning, we’re enjoying the final days of the era of simple virtualization. Soon we’ll be entangled in the knotted nomenclature of host/guest, privileged -- user, hardware -- assisted system virtualization on servers with multiple multithreaded multicore CPUs. Once we graft storage and network virtualization onto that terminological tree, each IT organization will have to rely on software -- or consultants, which are harder to carry around -- to help them map and navigate through their peculiar maze of physical and virtual entities and pathways.

There are two main rabbit holes that many implementers of growing virtualized enterprises haven’t uncovered: the difficulty of identifying and addressing critical problems that manifest as something short of a full failure, and the fact that blind trust in a virtualization solution’s tendency to do the right thing guarantees reduced return on investment.

Virtualization makes wider distribution of previously tightly clustered solutions irresistible. It’s obvious that this alone doesn’t translate to better performance, and when multiple virtual machines reside on the same host and publish the same services, you’ve added as much complexity as protection.

When metrics such as latency, connection capacity, and dropped connections indicate a problem in one virtual machine but not in others that occupy the same host, troubleshooting gets painful quickly. Guest OSes aren’t aware that the hardware they see doesn’t actually exist. The virtual LANs, host bus adapters, volumes, memory, and CPUs that look local to the guest are mirages created by the VMM. If the majority of guests are happy living in this unreality but one or a few go into decline, the diagnostics and work -- arounds that experienced admins apply to the one -- system, one -- OS model quit working.

As your use of virtualization grows in scale and purpose, you need to match your virtualization solution and its specific deployment to the capabilities of your hardware. System virtualization does paint over the physical differences among systems, but relying on that convenience will reduce your investment return. Look at the aggressive road map of highly relevant technology advances that AMD has made, and will make through the end of 2006, and ask yourself whether your virtualization and hardware purchasing strategy specifically takes them into account. It likely does not, and if so, your operation’s return on its system virtualization investment might be short by a third of its potential.

Virtualization adds to the skills that your IT staff must possess because the headache -- inducing problems that take IT staff and developers down a rabbit hole now will take them down deeper, more complicated ones when virtualization becomes the de facto means of placing new capacity online.