VMworld 2007 was held in the Moscone center in San Francisco on September 11-13. You can access all the keynote sessions here. Attendance was in the 10,000 range this year, as opposed to 1500 a couple of years ago. Virtualization is becoming “mainstream”.
Diane Greene’s keynote
Diane Greene, VMware’s co-founder and CEO, gave the initial keynote. On a personal note, I had not seen her for about 5 or 6 years, and it was a kind of painful reminder of how much time flew since the beginnings of HP Integrity VM
The big deal, in my opinion, was the announcement of VMware ESX 3i. This is basically “VMware in your pocket”, at least as far as demos are concerned. That is not something that you care about much in the data center, what you care about is facilitating deployment, and the demo pretty conclusively showed the benefits. Essentially, you unpack the server, and in a few minutes, it’s ready to run virtual machines.
VMware is certainly not the first one to use a standalone Hypervisor. The IBM Power 5 hypervisor has essentially been architected like that for a while. Just like for IBM, ESX 3i is intended to become a part of the firmware of the machines. Once you say that, it becomes obvious why VMware is interested in doing that: it’s all about control. With all the talk about Microsoft Viridian, i.e. Microsoft building an hypervisor directly into the operating system, VMware was at risk to lose control. So building the hypervisor directly into the hardware is a very smart move.
On the other hand, the explanation of the difference between an OS and an hypervisor was a bit belabored. When VMware states that “the RedHat console OS takes 2G of footprint”, it is, I guess, not memory (not on x86, at least). So that’s probably disk. But making the hypervisor a separate component is a bit like making the Linux kernel a separate component. As the GNU folks are fond of pointing out, a kernel by itself does not do much. And a Linux kernel on x86 is also in the order of a few megabytes, not a few gigabytes.
According to this article, VMware co-founder Mendel Rosenblum predicts the death of the operating system. I once made a somewhat similar prediction, although at the time, I thought that it would disappear from view, not from existence.
Both positions are closer than it may appear at first. Rosenblum and I both predict the disappearance of the OS as somewhat irrelevant to the end user. Rosenblum thinks that it will become irrelevant because it no longer controls the hardware directly, its role being reduced to providing application programming interfaces to the applications. I actually agree with this point of view. Otherwise, I would not have initiated another virtual machine technology, HP Integrity VM, and still be working on it today. As a side note, when we started that project, we negotiated with VMware in general and Rosenblum in particular.
But I also stand by my other prediction, that operating systems also fade into irrelevance on the user side as well. This is not yet true for personal computer operating systems, but it is already true of the majority of operating systems we use today:
- You probably don’t know what operating system the many electronics components in your car are running.
- Similarly, the OS in your set-top box, in airplane entertainment systems, in your MP3 players and GPS devices are probably not very relevant to how you use these devices.
- Finally, on a larger scale, the operating systems behind services like Google, the delivery of your e-mail or IP phones are also, I would bet, not part of your decision when choosing one service or another.
I just came across a very simple virtualization benchmark. This kind of benchmark shows some of the problems with virtualization: it usually works pretty well at limited load, but you pay the price at high load. This appears to be true of any virtualization technology today, even if it varies in the details.
Benchmarking often boils down to a petty fight. One get a true sense of just how reliable benchmarks can be by comparing the Xen and the VMware results for what appears to be the same benchmarks (but, oddly enough, with opposite conclusions).
Unfortunately, hardware assistance for virtualization, like Intel VT and VT-i technologies, does not seem to help much there (yet). It seems like it was designed primarily to make virtualization easier. As a result, we get for example Xen running Windows guests. But it does not really help with performance (summary).
This is interesting news, for two reasons. The first one is that graphics performance has been a main bottleneck for desktop virtualization for a long time, and more importantly, a functional bottleneck. In particular, it excluded any kind of “modern” gaming in a virtual machine. Having solved that is really neat, both technically and as a way to make virtualization more mainstream.
The second reason is that, if indeed we are talking about a fully supported feature, I believe that it appeared on the Mac version first. Granted, it has been present in a limited form in Workstation 5.0, for a little more than one year, but the feature is not even advertised in VMware Workstation 5 datasheets. With the Intel Macs, VMware found itself another mass market for its workstation products, one with presumably a much better attach rate, and more importantly, a market where they were beaten to the gates by Parallels.
Once more, innovation is fueled by competition. Good for Macintosh users…
Microsoft recently published a video of their upcoming Longhorn virtualization. Interestingly, they demonstrate a feature that they claim no competitor can match, namely an 8-core virtual machine. I’m really curious to see the final product. Being in the field, I know exactly what kind of problem virtual machines run into with scalability.
A key problem is relatively simple to explain, and having explained it to many HP customers, I see no reason not to talk about it on this blog. When you schedule more than one virtual CPU, there are essentially two ways of doing it.
- You can use something called gang scheduling. In that case, all virtual CPUs run at the same time. One major benefit is that if a virtual CPU is waiting for a lock, the virtual CPU that holds the lock is also running. So there is no major increase in lock contention, a key factor in scalability. The major drawback is that if you have an 8-way virtual machine with 1 CPU busy, it actually consumes 8 CPUs. That is not very good use of the CPUs.
- An alternative is to schedule each virtual CPU individually. This is much more difficult to get right, in particular because of the lock contention issue outlined above. On the other hand, the benefit in terms of CPU utilization for virtual machines that use only some of their virtual CPUs are enormous.
So here is a test I’m interested in running on Longhorn virtualization when it becomes available: if I have two 4-way virtual machines on an 4-way hardware, and if I start one “spinner” process in each that counts as fast as possible, do I see:
- 4 processors pegged at 100%, with the two spinners running at half their nominal rate, since they each get essentially 50% of one CPU? As far as I know, this is the behavior for VMware, and it’s characteristic of gang scheduling.
- 2 processors pegged at 100% and 2 processors sitting mostly idle, with each spinner getting 100% of a CPU? This is the behavior of Integrity Virtual Machines.
The bottom line is: there is a serious trade off between scalability and efficient use of resources. If Microsoft managed to solve that problem, kudos to them.