I worked on VMware's virtual machine monitor from 2000 to earlier this year. I overlapped with Michael Mullany, and his article is a fair recollection of our efforts. The more technical crowd here might appreciate a few additional thoughts.
1. Everywhere he talks about "memory", he really means "privileged virtual memory operations." Flushing the TLB, altering the virtual to physical mappings, changing address spaces, etc. Ordinary loads and stores have always been directly executed at native speed. He also merges "apache" (lots of context switches) and "compile" (lots of process creation and page faults) into the odd-sounding "apache compile").
2. In my opinion, paravirtualization was first a hack, and only retrospectively framed as a performance optimization. By hacking up Linux, the Xen folks were able to get a viable system working much more easily than would have been possible for unmodified kernels. The notional perf advantages of this approach have, IMHO, not been convincingly shown, and RVI/EPT hardware impressively raise the bar for ever demonstrating it.
3. Although I worked on it, I would be very shy about claiming "hypervisor" as a VMware invention. First, it is not an entirely accurate description of ESX, which keeps a much more rigid separation of the "monitor" (responsible for providing virtual CPUs, memory management hardware, and devices) from the "vmkernel" (responsible for driving IO and keeping VMs out of one another's way) than most people imagine when they hear the term "hypervisor". But most importantly, I first remember hearing the term applied to kernels from the first virtualization golden age, in the 1970's. We have stood on these giants' shoulders enough without claiming their inventions for ourselves.
3. Although I worked on it, I would be very shy about claiming "hypervisor" as a VMware invention
One of my fond childhood memories: reading IBM VM/XA manuals
http://www.vm.ibm.com/history/ . They had everything you ever wanted to know about hypervisors.
That's a reasonable interpretation, it just isn't my recollection of the workloads we used for benchmarking. I remember running the actual httpd server under synthetic loads, and compiling the Linux kernel make -j <bignum>.
I think this article was in response to some of the issues that were mentioned as a motivation for Github's move away from Engineyard... Specifically, Github mentioned slow IO issues on virtual machines as a significant issue.
FWIW IO performance on Joyent is abysmal, and they supposedly use Sun's latest virtualization technology.
It sounds like the problem is not with the technology but with how it's managed... It's easy to partition memory and CPU resources, but not as easy to partition IO resources.
I'm still waiting for virtual hosts that are paired with their own dedicated solid state storage rather than sharing one hardware IO system or using slow network storage.
Hi Grand -- this is michael. Yes this was to respond to some of the perceptions out there that virtualization = slow. It's really not (at least now, it isnt' - as long as you know what you're doing, some of the tech docs to get the new hardware virtualization features working seem a bit daunting). And on the other hand, there's no alternative to having enough hardware capacity to meet your requirements. Virtualization can't make i/o capacity appear from thin air.
1. Everywhere he talks about "memory", he really means "privileged virtual memory operations." Flushing the TLB, altering the virtual to physical mappings, changing address spaces, etc. Ordinary loads and stores have always been directly executed at native speed. He also merges "apache" (lots of context switches) and "compile" (lots of process creation and page faults) into the odd-sounding "apache compile").
2. In my opinion, paravirtualization was first a hack, and only retrospectively framed as a performance optimization. By hacking up Linux, the Xen folks were able to get a viable system working much more easily than would have been possible for unmodified kernels. The notional perf advantages of this approach have, IMHO, not been convincingly shown, and RVI/EPT hardware impressively raise the bar for ever demonstrating it.
3. Although I worked on it, I would be very shy about claiming "hypervisor" as a VMware invention. First, it is not an entirely accurate description of ESX, which keeps a much more rigid separation of the "monitor" (responsible for providing virtual CPUs, memory management hardware, and devices) from the "vmkernel" (responsible for driving IO and keeping VMs out of one another's way) than most people imagine when they hear the term "hypervisor". But most importantly, I first remember hearing the term applied to kernels from the first virtualization golden age, in the 1970's. We have stood on these giants' shoulders enough without claiming their inventions for ourselves.