Network stack cloning / virtualization patches

Juli Mallett jmallett at FreeBSD.org
Fri May 30 11:33:02 PDT 2003


* Sean Chittenden <sean at chittenden.org> [ Date: 2003-05-30 ]
	[ w.r.t. Re: Network stack cloning / virtualization patches ]
> > at http://www.tel.fer.hr/zec/vimage/ you can find a set of patches
> > against 4.8-RELEASE kernel that provide support for network stack
> > cloning. The patched kernel allows multiple fully independent
> > network stack instances to simultaneously coexist within a single OS
> > kernel, providing a foundation for supporting diverse new
> > applications, including:
> > 
> > - Enhanced virtual hosting (think of jails with its own private set of
> > network interfaces, IP addresses, routing tables, ipfw and dummynet
> > instance etc.);
> > - High-performance real-time network simulation / emulation;
> > - Fully isolated overlay VPN provisioning (using IP tunnels), including
> > the possibility of creating nested VPNs.
> > 
> > The network stacks are embedded in new resource container entities
> > named "virtual images". Each process and network stack instance within
> > the system has to be associated with a virtual image, which in effect
> > becomes a light or pseudo virtual machine entity. Additional goodies
> > include the possibility to control some other resources besides the
> > network stack, most notably the independent CPU load and usage
> > accounting, as well as feedback-driven proportional share scheduling
> > among virtual images. For more details, check the above URL.
> > Note that the patch was designed to allow all existing applications and
> > utilities to run unmodified on the patched kernel, so no recompiling of
> > the userland is necessary.
> >
> > Hope you'll find use for the new framework :-)
> 
> Has anyone stepped forward to possibly shepherd this code into the
> tree?  I am highly interested in this code and would like to see it
> incorporated into the base system (read: -CURRENT, before 5.2).  After
> looking at the TODO, I realize that this patch isn't 100% yet, but can
> it be broken down into a smaller set of commits?

Has anyone looked at making the patch work with CURRENT?  Does this do
anything to degrade performance of UP systems with no (0?) virtualised
images running?  Does it make the locking situation much worse?  Can it
be stripped down to minimal, clean, well-architected diffs to accomplish
a centralised goal, rather than a "Network+goodies, random subsystem
overhaul"?  Those are probably good questions for someone to know the
answers to (by looking at the code, or someone trying such) before it
gets too close to the tree.

If this is your priority patch, hunting down someone with serious
network\ stack-fu to review the diff, and whatnot, would probably be
a good investment of your time in that regard.

Thanx,
juli.
-- 
juli mallett. email: jmallett at freebsd.org; efnet: juli;


More information about the freebsd-hackers mailing list