From: by way of Sam Vilain (sam_at_vilain.net)
Date: Fri 14 Feb 2003 - 14:56:19 GMT
> "Plex86 has been completely overhauled, and simplified to be a user
> (application) code only Virtual Machine technology. For running user
> code, many of the heavy weight x86-VM techniques are unnecessary. But
> the bonus is, Linux can easily be made to run inside the plex86 VM, so
> that the kernel is actually 'pushed down' to user privilege level. This
> has been demonstrated on both Linux 2.4 and 2.5 kernels. Thus, Linux can
> run in a plex86 VM without the need for any heavy virtualization. My
> goal is to keep the code base trim, tight, auditable and get to usable
> releases quickly. And to favor those goals over adding unnecessary
> complexities. The first milestones have just been reached, so it's still
> early in development. There are email lists available on the main plex86
This seemed to me to be encroaching on UML's territory. My initial
thought was damn... so they're abandoning writing a free VMware clone,
and re-inventing User Mode Linux!
Having said that, I found UML quite difficult to actually get going to
debug the kernel I was toying with when I last tried, largely because the
changes to the client kernel for UML are so sweeping.
I guess this is because UML is a set of patches to turn Linux into a
userland executable, whereas Plex86 emulates instead an x86 host (without
the code rewriting necessary for the braindead x86 instructions that don't
generate an fault in user mode). So the changes are more, a
fundamentally different approach.
I can't help but see three different projects - UML, vserver, plex86
working towards similar but complementary goals, but in marginally
incompatible ways with each other.
Each project is virtualising different parts of the complete picture;
- Process partitioning within a kernel - the five line (ok, I'm
exaggerating) original vserver patch, plus the linux capabilities
system. UML also fits into this category without skas-mode.
- Network stack virtualisation - IP seperation in the first vserver
patch, per-socket structures in ctx-15+, some more in Lyashkov Alex's
patches, and of course iptables.
- Memory management virtualisation (UML skas-mode ?)
- Filesystem namespace/space sharing within a host system (chroot + my
immutability attribute extenstion for vserver)
- Filesystem namespace/space sharing between two seperate filesystems
(UML's UBD, and *I think possibly* lvm2's device mapper)
- Complete kernel `boot space' virtualisation within a process - Plex86.
- Virtualisation of many kernel structures in one fell swoop - UML in
- Swallowing of multiple processes into a single process (ish) - UML in
Of course, there are other projects (FreeVSD, FreeBSD's jail system,
Mach/Hurd, L4/Ka, VMWare, S/390, Solaris domains to name a few) which do
similar things but are more diverged for various reasons so I have left
out of the loop.
There is a large crossover of scope here, and I bet each project has
encountered problems that others have solved.
It would be extremely nice if through the merging of these projects, one
could perform selective virtualisation and/or various forms of `jailing'
*of individual kernel subsystems* in a very independant manner. If the
subsystems scheduling operation were abstracted far enough, it may even be
possible to attach some of the QoS modules for controlling their allocation
schemes. Class-based queuing for the kernel scheduler or I/O elevator
would be pretty damned neat. Memory management could even fit the model,
but only if you consider the unit of memory to be ( memory size * seconds
Then, depending on which ones you choose to use, you get something that
looks like UML, vserver, or plex86.
Perhaps people could raise the fundamental technical challenges they see
befalling this (obviously?) desirable goal, and all will benefit.
Apologies for the cross-post; but I think this issue is related to all
three projects. Please remember to drop out lists which you don't think
will be interested in your comments in your replies!
-- "Discovery consists in seeing what everyone else has seen and thinking what no one else has thought." - Albert Szent-Gyorgi -