About this list Date view Thread view Subject view Author view Attachment view

From: Allen Parker (allenp_at_hardcore-linux.net)
Date: Fri 03 Oct 2003 - 17:02:54 BST

> > > 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 ...
> Jacques' VServers patch is really nice work, and we've got quite
> a bit of experience using it. However, the level of isolation it
> provides between different users is actually pretty low. It might
> be OK for a machine with broadly co-operative users, but
> its pretty easy for a malicious user to hose the machine, e.g. by
> causing the OS to do huge amounts of work on its behalf.
> It's very tough to do real isolation within a 'nix kernel. There
> are just so many interactions between processes that can cause
> "QoS crosstalk" e.g. competition for locks and shared resources such
> as the buffer cache.
> Ensim's 'private virtual server' product is the most complete
> attempt at doing this that I've heard of. They've made a real
> effort to account memory usage, even in the buffer cache. I'm
> still sceptical as to whether it could provide isolation in the
> presence of malicious user.

Ensim? Have you ever heard of Sw-Soft's virtuozzo? Probably not... Virtuozzo
is THE MOST complete when it comes to throttling vservers, you can manage
them down to the CPU cycle, I can manage a Virtuozzo vps's memory useage
down to the BYTE of ram/swap...

At a $6k startup cost and $14 per vps per month, Ensim isn't the best
solution for the job. Virtuozzo is $1 per Mhz with no monthly cost.
> We built Xen for use in the XenoServers project, which aims to
> create an 'Open Infrastructure for Global Distributed Computing'.

You are hereby banned from using "buzzwords."

> We envisage Xenoserver execution platforms scattered across the
> globe and available for any member of the public to execute code
> on. The sponsor of the code will be billed for all the resources
> used or reserved during the course of execution. You'd be able to
> create on-demand 'dedicated servers' with tailored amounts of
> RAM, CPU, net b/w, disk b/w and disk space, and run the OS of
> your choice. For example, you could buy a slice of a machine to
> run a counterstrike server for a few minutes while you play a
> game with a couple of friends. You'd pick the server location
> such as to minimize the maximum RTT between the server and the
> players.
> In this kind of environment, we need to ensure people get what
> they pay for, and hence we really care about isolation. Our
> approach with Xen is to provide guest OSes with strict minimum
> resource guarantees, but enable them to make use of resources
> that are otherwise idle on a proportional best-effort basis. For
> example, we have plans to allow currently unallocated memory to
> be used by domains as a 'last chance' swap cache, or as a shared
> buffer cache for files accessed from a special network file
> filesystem (based on OpenAFS). This way, we get most of the
> benefits of sharing back, but in a controlled fashion.
> The actual CPU overhead of having multiple operating systems is
> actually very small. In the SOSP paper we show results for an
> application running on 128 guests OSes vs. running 128 copies on
> the same OS. There's a memory overhead of running multiple guest
> OSes, but it's only ~20KB per-guest in Xen, and a couple of MB
> for a Linux kernel and its non-pageable data structures.
> As Keir says, the vservers patch applies pretty cleanly over the
> xen patched linux, so you can always do a combination of both
> techniques. In fact, I know of at least one heavily used
> Xen/Linux installation that has a four month uptime that has
> been doing exactly this. None of the users seem to have noticed
> they're running over Xen. ;-)
What exactly are you trying to do here? Sell a product? Get us to "switch"
to Xen? Before the emails to this list, I'd never heard of Xen. How about
you just tell us in plain words why you guys sent an email about something
not directly related to the vserver project?

> Ian

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 03 Oct 2003 - 17:30:11 BST by hypermail 2.1.3