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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/