When I was planning the infrastructure for my revitalized lab, I intended to have VMware play a central role in my network and application testing. While that objective was eventually met, it didn't turn out like I had planned, and the path was extremely circuitous, involving multiple changes in strategic direction. Now with the recent release of VMware ESX 3.0 and VMware Server 1.0 (a replacement for the GSX line), I'm having to revisit the decisions all over again.

I need to be able to run a wide variety of systems so that I can test network applications and protocols across a large number of platforms. VMware provides a great platform for that kind of work. For instance, I might need to look at the way that different operating systems implement a specific technology within their networking stacks, while another project might require me to compare the security protocols that are offered by a handful of e-mail servers. This kind of work is a natural fit for VMware, since it lets me avoid having to buy and manage a dozen different PCs that are all running different operating systems.

Originally my plan was simply to use the top-of-the-line VMware ESX 2.5 platform for this. Even though it's a little bit overkill for my expected usage, its performance and management features make it clearly superior to the mid-tier GSX platform, and also promise to translate into better overall testing.

In particular, whereas GSX runs as a system service under Windows or Linux, and thus relies on the operating system to provide basic file I/O and memory management, ESX employs an independent microkernel that manages these types of resources directly, giving it much better performance (ESX does use Linux for the "console" and some rudimentary system services, but the important stuff is handled by ESX directly). Another benefit to ESX is that it exposes system-management interfaces via a local /proc interface and also through SNMP, while the only management interface for GSX is a relatively limited WMI performance counter, and that's only available if Windows is used for the host operating system.

I knew that ESX had some peculiarities that would take some effort to overcome. For example, I knew that direct hardware management translated to stricter hardware requirements, and that using a relatively niche platform meant having less packaged software available. I also knew that ESX supported fewer guest operating systems than GSX. But I figured I could overcome these hurdles, and even if it took more up-front time to get things working, in the end it would take less time and energy than trying to manage multiple PCs. I was wrong on all these counts.

Making Mistakes

I was not at all prepared for just how strict the hardware requirements for ESX really were. Although the documentation lists a couple of dozen SCSI controllers that are listed as "supported," I figured this was just the usual narrow list of "endorsed" hardware, and that ESX was really a lot more flexible than that. But given the way that ESX manages resources directly, it actually does require specific hardware, and if a device isn't on the approved list then it probably isn't going to be recognized.

For instance, I'd already bought a box of SATA II drives to use for this project, but none of the SATA II controllers were recognized by ESX. I was eventually able to use an Intel SRCS14L SATA I controller that happened to share a SCSI driver with a supported card, but a long-term solution would essentially require switching to real SCSI, which conflicted with my own strategy of using SATA II everywhere.

I ran into similar kinds of problems with some other devices too. For example, I had picked up a Crystalfontz CF635 LCD panel for displaying real-time performance data from ESX and the virtual machines, but the USB drivers in ESX couldn't find that device either. Similarly, there was no support in the Linux kernel for my motherboard's hardware sensors, meaning that I couldn't even monitor system health remotely like I do with all my other systems.