VMMs and Over-commitment

[Neal H. Walfield]

At Thu, 2 Aug 2007 21:05:27 +0200,
<address@hidden> wrote:
> Yet, I'm not sure the option of decentralized management should be
> completely discarded. Think of virtual machines: In this case, it's
> totally out of question to have a central resource manager that controls
> all allocations within the guest systems. The guests want to keep total
> control over how things are managed inside their VMs.

Totally out of the question is quite exaggerated.  VMWare ESX Server
implements a number of techniques to facilitate the over-commitment of
memory including paging, ballooning and content sharing [1].

ESX Server introduces another layer of paging.  The decisions are, of
course, less informed (as the VMM has less data) and can result in
double paging.  To this end, ESX uses a randomized strategy.

To avoid paging, ESX uses so-called ballooning.  A driver is loaded
into a guest OS that interacts with the hypervisor.  The hypervisor
signals the balloon to change its size according to memory pressure
and its current allocation strategy.  When the balloon grows, the OS's
own memory management strategy comes into effect.  The memory
allocated to the balloon is then returned to the hypervisor.

Finally, ESX implements context based sharing.  Using idle CPU time,
it scans memory looking for identical pages.

> Traditionally, the resources for VMs are allocated statically, which is
> a total waste of course.

VM/370 implemented demand paging [2].


> So it is desirable to have a mechanism where
> the guests have full control over their VMs, yet can interact with the
> host to dynamically manage resources for the whole VM. (A while back I
> learned that Xen is working on something like that; no idea what became
> of it...)

This is consistent with my current direction.  My goal is to allow
principals to control to what ends resources they are allocated are
used without requiring them to micro-manage each separate activity.

> The current popularity of VMs shows that in many cases, the benefits of
> the strong isolation outweigh the disadvantages of missing
> centralization and integration.

I disagree.  The commodity use of VMs to isolate programs demonstrates
a deficiency in commodity operating systems.  That many researchers
are focusing their efforts exclusively on VMs rather than considering
how to improve OS interfaces is another, separate problem.  This has
been identified by others [3].

> Of course, the ability to relatively
> easily create custom sub-environments in the Hurd is not quite
> comparable to full-blown VMs; yet it might be an interesting direction
> to look in...

I'm not sure what you mean here.  I think you mean: providing support
in the OS for isolation may be an interesting direction.  If so, I
whole-heartedly agree.

Thanks,
Neal


[1] Memory Resource Management in VMware ESX Server, by Carl
    A. Waldspurger (2002).

[2] VM/370-a study of multiplicity and usefulness by L. H. Seawright
    and R. A. MacKinnon (1979).

[3] Hype and Virtue, Timothy Roscoe, Kevin Elphinstone, Gernot Heiser
    (2007).