From: Keir Fraser (Keir.Fraser_at_cl.cam.ac.uk)
Date: Fri 03 Oct 2003 - 08:22:54 BST
> > > I noticed that the SOSP Xen paper briefly mentions Jacques Gelinas' work
> > > on VServers (http://www.solucorp.qc.ca/miscprj/s_context.hc). While
> > > Jacques' work hasn't attracted as much public attention as other Linux
> > > virtualization efforts, I've personally found the approach and concepts
> > > quite fascinating. Among other things, most of the code implementing the
> > > contexts is architecture-independent (save for a few syscalls added to
> > > arch/*/kernel/entry.S). So, thinking aloud here, I'm wondering in what
> > > circumstances I'd prefer using something as architecture specific as
> > > Xen over something as architecture independent as Jacques' VServers?
> > > (Granted VServers can't run Windows, but I'm asking this from the angle
> > > of people looking for resource isolation in the Linux context.) Among
> > > other things, VServers are already in use by many ISPs to provide
> > > simultaneous hosting of many "virtual machines" on the same box while
> > > maintaining strict separation between machines and still providing a
> > > secure environment.
> > One of the main differences is that we provide resource isolation, so
> > that each virtual machine only gets the resources that its sponsor
> > paid for. This allows companies providing virtual servers to
> > provide differentiated service according to the amount paid.
> although the resources are usually shared in vserver environments
> (this _is_ considered an advantage) Jacques' VServers allow the
> administrator to limit the resources available to each virtual
> server (like memory, file handles, processes, cpu power and disk
> space), which should provide similar functionality ...
Okay, but there's nothing beyond the limits and quotas that Linux
already imposes on processes or process groups, right?
Quite apart from service differentiation, what happens if a vserver
maliciously tries to chew up disk bandwidth, buffer cache, network
bandwidth, CPU, and/or memory? There seem to be issues if you're
running mutually untrusting users over the same host OS...
However, the vserver kernel patch applies quite cleanly to our
port of Linux, so both approaches can be used on the same machine. Xen
can be used to carve a large server into several strongly-isolated
pieces, and vservers can be used to allow finer-grained sharing.
For the time being this may be a "sweet spot", although we have
plans to incorporate controlled and opt-in resource sharing into Xen
in the future.