BSDnewsletter.com

In late 2006 and in January 2007, Matt Dillon implemented his vision of a virtual kernel in DragonFly. Details are in the vkernel(7) manual page which includes how to setup the filesystem, compile the vkernel, enable it, setup networking, and how to run the virtual kernel.

In January, Matt Dillon provided some details about DragonFly's new "virtual" kernel technology. The following are the questions and answers.

What existing technology is this comparable too? (Anything else in the BSD world?)

The technology is similar to Linux's UML (User Mode Linux).

Any interesting performance benchmarks yet?

Performance is pretty much as expected. System calls cost around 3uS and page faults cost a bit less (due to not necessarily having to be forward to the virtual kernel, since the real kernel maintains the page tables). Other then that instructions run at full speed.

How does its performance compare with other technologies?

Very fast booting. I haven't compared the performance with other technologies but I expect it would depend heavily on the type of work. Paging or system-call-heavy workloads would suffer the most.

This initial cut does not try to optimize system calls or the VM system all that much, but it is quite clear to me that optimizing the VM system at least is very doable. We also haven't optimized the virtual disk or virtual network subsystems much, other then implement mailboxes for signals so we could use SIGIO semi-synchronously without actually having the overhead of a signal handler.

Any examples of resources or amounts of memory used?

It uses almost precisely the amount of ram you tell it it has to play with. Real-kernel resources are extremely low. The real kernel has to maintain a vmspace and pmap for each of the virtual kernel's processes, but as with all BSDs the pmap's are all throw-away data and have little impact on real kernel resources.

How many virtual kernels possible to use on system? (Feel free to describe the system.)

Currently the virtual kernel wants to use all the memory you tell it it has, and that is the main limiting factor. It is possible with only a small amount of work to make the virtual kernel more memory-friendly, though, by having it use madvise() to free 'free' pages.

What is it currently useful for?

The most immediate use for us is that it allows us to test non-hardware-related kernel code in an environment that boots to a login prompt almost instantly. For example, filesystems, networking stacks, and mainline kernel code.

Virtual kernels can also be used to provide virtualized systems to third parties or for compartmentalized security purposes without having to dedicate an entire machine to the job. Virtual kernels work far better then jails if security is important since the interaction with the real kernel is minimal.

What do you plan to use it for? (Will you replace Xen, jails, anything else?)

Each has its place and its use. I don't think virtual kernels can wholesale replace any of those.

Where should I point readers for more information on using it? Where should I point readers for technical development details about it?

The wiki page (editor's note: the wiki page is now gone) and the manual page (vkernel) is all we have at the moment. I really should write up a technical paper on how it was implemented, because I did add a number of generic but powerful features to the real kernel to support virtual kernels (mailbox signals, MAP_VPAGETABLE mmap's, and vmspace_*() system calls to control vmspace switching).

When should an end-user start using it? (Is it stable now? Or are important new features still in development.)

It should be reasonably stable. The only thing not implemented are logical descriptor tables (user LDT).

A user should play with it if he has a use and an interest in it, or just to play around.

And I am curious ... can a virtual kernel host another virtual kernel?

Yes, though the feature is not well tested and I expect it would be rather slow.

How do virtual kernels work on SMP systems?

At the moment the virtual kernel builds as a UP kernel. A SMP virtual kernel isn't too much of a leap... all it really has to do is rfork(). Certain mechanisms (IPI messaging mainly) would have to be implemented.

Is there any long-term plan to allow virtual kernels to control specific items of host hardware?

No. Frankly I do not think it is a good idea to allow any production virtualization mechanism to ever have direct access to hardware. It destroys the layering that gives virtualization stability and security... no matter how good the implement is.

As a debugging tool it might be useful, but that is about as far as I would ever consider taking it.

Matt also wrote about using it as a debugging tool: I think it would be useful too, but I also think someone else will have to take up the ball on implementing it. I've done the hardest part... making the vkernel work in the first place. Now hopefully those with an interest in expanding it will start working on it :-)

Discussion

BSD Links