From: Ryan Cumming <bodnar42@phalynx.dhs.org>
To: Jeff Dike <jdike@karaya.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Special Kernel Modification
Date: Sun, 4 Nov 2001 18:14:12 -0800 [thread overview]
Message-ID: <E160ZHB-0001Ae-00@localhost> (raw)
In-Reply-To: <200111050158.UAA05147@ccure.karaya.com>
In-Reply-To: <200111050158.UAA05147@ccure.karaya.com>
Hey Jeff,
> A virtual machine would be an administratively easy way of doing this.
>
> Let the 'app' be a VM with the real apps installed inside. The users would
> effectively be confined to a *file* on the host, not merely their home
> directories.
>
> My (biased :-) recommendation would be User-mode Linux
> (http://user-mode-linux.sourceforge.net), but VMWare would work as
> well.
I'm afraid that would scale horribly on anything greater than a very modest
load:
1) There is a fairly significant overhead due to running inside a VM, which
would certainly pile up over multiple invocations. Besides the overhead of
the VM, you have the have the additional overhead caused by such things as
having multiple running kernels doing exactly the same thing, all running
seperate copies of the required system daemons.
2) Upgrading/changing the system configuration would require modifying -all-
of the VMs. This could be partially alleviated by using an NFS root, but then
the overhead mentioned above becomes even more looming
3) Implicitly shared memory no longer works too well, and this is one of the
reasons Unix is so strong as a terminal server:
You have thirty people running StarOffice from /usr/bin, and because
they've all mmap()ed the same binary, the read only portions are all shared,
and will definitely stay in memory in the event of memory pressure. The same
things goes for all the libraries and mmap()'ed data files StarOffice uses,
including some pretty hefty ones such as glibc. Even many of the writable
pages will be shared until someone decides to write to one of them, and then
the writer will get a private copy.
Now, try 30 people all running from VMs. They all must have a seperate copy
of the otherwise sharable portions of StarOffice, and all of its
dependancies. Memory pressure quickly rises, and it will start swapping out
one copy of StarOffice in favour of an identical portion of another copy (!).
System quickly becomes unusable.
So, to summarize, you could use a VM, and it'd work well for containment, but
it'd be pretty useless as far as performance, ease of administration, and
scaling go. Comments?
-Ryan
next prev parent reply other threads:[~2001-11-05 2:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-05 0:01 Special Kernel Modification Lonnie Cumberland
2001-11-05 0:19 ` Ryan Cumming
2001-11-05 0:29 ` lonnie
2001-11-05 1:04 ` Jan-Benedict Glaw
2001-11-05 3:04 ` Mike Fedyk
2001-11-06 0:34 ` Jorgen Cederlof
2001-11-06 0:38 ` lonnie
2001-11-05 0:22 ` Alan Cox
2001-11-05 0:39 ` Phil Sorber
2001-11-05 0:38 ` Rik van Riel
2001-11-05 1:04 ` Jeremy Jackson
2001-11-05 1:58 ` Jeff Dike
2001-11-05 2:14 ` Ryan Cumming [this message]
2001-11-05 4:02 ` Jeff Dike
2001-11-05 3:13 ` Ryan Cumming
2001-11-05 5:52 ` Jeff Dike
2001-11-05 5:30 ` Ryan Cumming
2001-11-05 14:22 ` Jeff Dike
2001-11-05 16:53 ` Andrea Arcangeli
2001-11-05 20:18 ` Jeff Dike
2001-11-05 19:05 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2001-11-05 0:37 John Weber
[not found] <E160aCK-0001Fs-00@localhost.suse.lists.linux.kernel>
[not found] ` <200111050552.AAA06451@ccure.karaya.com.suse.lists.linux.kernel>
2001-11-05 6:22 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E160ZHB-0001Ae-00@localhost \
--to=bodnar42@phalynx.dhs.org \
--cc=jdike@karaya.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.