From: Cliff Schmidt (cliff_at_bea.com)
Date: Mon Mar 01 2004 - 18:07:08 PST
The Denali paper shows another example of applying the virtual machine
monitor concept in order to "carve a physical machine into multiple
virtual machines." However, the primary difference from Disco is that
Denali is much more focused on optimizing the performance and
scalability of many virtual machines on one node.
The paper does a good job of explaining the motivations for this
project. Like the Porcupine paper from last week, this paper is
interested in designing a system that supports the demand for highly
scalable Web services (not necessarily SOAP Web services). As I
commented on the Porcupine paper, this appears to answer a real
industry demand that I have noticed in the last couple years, which
is now being called Grid Computing.
The distinguishing characteristic of Denali, compared to other virtual
machine monitors, is that it does not faithfully represent the under-
lying hardware. In an effort to maximize performance, Denali:
- uses a subset of the x86 ISA
- adds to additional instructions (a VM terminate instruction and an
"idle with timeout" instruction, which turns out to make a big perf
difference by allowing VMs to halt their virtual CPU to lend the
unneeded physical CPU resources to other VMs)
- adds additional virtual registers
So, this of course, means that it does not provide backward
compatibility for existing x86 operating systems. Unfortunately,
the authors had not yet been able to port an existing operating
system to Denali in order to talk about the porting cost; instead,
they created a new host OS, Ilwaco, so that they could run some
applications for performance and scalability checks. Needless to
say, this is a big disadvantage to getting industry acceptance,
but I think the isolation issues and the relatively high
performance make it a reasonable thing to consider. Since the
beginning of Web hosting (as the authors point out), there has
always been a compromise between how dynamic an environment a
hosting service is willing to give its customers and how secure
and isolated that environment can be. If you are considering
hosting hundreds or thousands of Web services on the same node,
this isolation must also be scalable, and that is where Denali
shines.
Here are a few other miscellaneous thoughts:
- In the discussion of the problem with global namespaces in
section 2.1.2, I thought the authors were going to contrast this
with the Opal system's use of capabilities within a single
address space. I guess I thought that could have been an
approach to dealing with sharing across VMs -- you can't access
something that you can't name.
- Speaking of Opal, it's interesting that in this recent paper,
the design for Denali is based on a 32-bit address space, as
compared to the 64-bit address space that Opal was designing
for ten years ago. Although 64-bit operating systems are far
less common today, it seems like a reasonable thing to consider
for a highly scalable Internet service hosting architecture.
- I liked the idea of swapping out VMs to disk and found the
problem of delivering asynchronous interrupts to be interesting.
It reminded me of a similar problem I've seen with delivering
asynchronous callbacks to a Web page that has made a call, but
is no longer active.
- The approach on CPU virtualization made me think of how
Lottery scheduling could be used (really only a part of it
since the VMs aren't generally cooperating) in the approach
of removing a VM from scheduler consideration on a idle-with-
timeout instruction, but then compensating for the idling with
a higher scheduler priority for its next quantum
- I wasn't completely convinced why the network stack should
belong to the supervisor VM, as opposed to the isolation
kernel.
This archive was generated by hypermail 2.1.6 : Mon Mar 01 2004 - 18:07:09 PST