Practical X86-virtualization, as pioneered by VMware, has profoundly changed IT, in a way that no other technology advance has ever done before. Once perfected, the insertion of a thin virtualization layer (the “hypervisor”) is as close to invisible as one can imagine, especially given how remarkably it changes how we can use computers. The success of server virtualization has lead to speculation about network virtualization. What if we could construct multiple “virtual networks” on one physical network? Could a “network hypervisor” could be developed with comparable simplicity and results. We certainly have a slew of network problems where “virtualization” looks like an attractive solution approach. We seriously doubt that any such silver bullet can be found for networks, and here’s why.

Modern X86-virtualization began as a part of a computer system research effort at Stanford. The Stanford Lab has a long history of wanting practical and usable innovation, and for that reason wanted a way of running common software workloads on experimental hardware systems. Since most of those workloads ran on the X86, and at the time experimentation was easiest on MIPS architecture, they wanted a way to emulate the X86 on a different machine architecture. Emulating the X86 is a challenging problem because the X86 has evolved greatly over two decades, and as a result architecturally resembles San Jose’s Winchester Mystery House. The Stanford team made good progress, and once X86 emulation of any form seemed practical, the team focused their attention on the emulation of X86 workloads on the X86 (what we think of as virtualization), and VMware was born.

Ed Bugnion, VMware founder and founding CTO, recently returned to finish his PhD at Stanford by detailing the technical innovation done. It’s a fascinating story. Early on, the VMware team made two critically important decisions: (1) they would emulate the X86 so perfectly that all the major existing operating systems would run under virtualization in their binary form, completely unchanged and (2) they would minimize the performance penalty so that software brought to market with performance optimized for a given process generation CPU (e.g. 65 nm) would work with comparable or better performance when virtualized on a CPU from the next process generation (in the example, 45 nm). Most experts at the time thought achieving these goals was impossible. To be sure, it was very difficult. For example, virtualizing the existing operating systems depended on experimentally determining what specific X86 instructions actually did, which was not what the official Intel architecture manual defined (the existing operating systems made use of the actual behavior).

Despite the fact that task looked impossible, VMware made it work with the amazing result that one can grab an X86 server workload, convert it to a virtual machine form (P-to-V), plop it down on a shared virtualized server and it just ran. Amazing! This enabled server consolidation, it enabled running very different stacks on the same hardware, and it enabled shared and automated data centers, elastic computing, and so on. Amazing. Never have so many benefited so greatly from the work of so few, to paraphrase the old saying.

Can we do something similar with networks? Finding the elegantly simple network virtualization solution is all the more important because server virtualization is so simple and effective and begs to have the other system components adapt as transparently. For example, if you virtualize an application that runs on a set of physical servers, the virtual machines probably want to find each other and cooperate with each other over the network exactly as they used to (unchanged), using a variety of network mechanisms, including low level mechanisms like ARP. But if we build a big virtualized data center, and we can position our VM’s flexibly, how we keep all that “local” network traffic between the VM’s that are part of one application system from overwhelming the shared network? How can we create separated “virtual” networks and manage them as simply as we manage virtual machines. The sad answer is that we probably can’t in any comparable simple and elegant way.