Matthew Dillon wrote:
:Matt,
:
:We use VMWare Server at work. It does not have the same nice image management
interface and/or video capture as commercial counterparts. However, it is is
free and testing on it helps us out big time. We never concluded whether it
maked sense to pay for VMWare licenses, instead of using free shell scripts
legally available for free.
:
:I have used UML for development in the past. I even used bochs once to debug a
boot loader. All nice tools. Beats real hardware for me.
:
:Xen and KVM are significantly slower than commercial products due to hardware
switching. There is a GPLed product that works about as fast as VMWare's BT -
VirtualBox by innotek. Sun recently scooped them up.
You've tried them all pretty much. VirtualBox is the only one that's
actually open-source (well, bochs is too but bochs is a full simulator
and unusably slow). VB is very nicely documented too, though I get a
headache trying to read all that C++. I know several people using
VB on linux host systems.
The reason I ask is simply because I am trying to point out *the* major
issue for open-source systems when it comes to hardware virtualization,
that being the availability of an open-source solution. I have never
trusted VMWare to maintain compatibility with any longevity. VB has
a better chance and even though it is hard to gauge what Sun will do
with it, I'd rather it be Sun then MS.
:Don't you use something like VMWare for development and debugging?
We use vkernel's for development and debugging. Pretty much everything
except hardware device driver development can be done using a vkernel
and being able to gdb the kernel binary (gdb, not kgdb) on a whim is
rather nice. Kinda hard to beat a 5-second reboot, it makes the
engineering test cycle almost as short as hitting ^C and re-running a
program. I don't even bother to do a clean halt of the vkernel most of
time, I just pop it into it's DDB with ctl-\ and then kill it with ^C,
then restart.
One interesting side-effect of having a vkernel so easily accessible
is that it opens up kernel development to normal programmers. More
DragonFly developers have been dipping their fingers into the kernel
code in the last 6 months then in all the time before then. That alone
justifies the time spent doing it. Except for hardware device driver
development, the agonizing engineering cycle for kernel development
is completely gone now.
-Matt
:In production, we don't use any of these products - too slow and too much RAM
would be required.
:
:Sincerely,
:
:Igor Shmukler, http://www.elusiva.com
I have thought of the vkernel primarily as an aid to kernel development
(where performance is not a prime concern), not as a virtualisation
solution that will compete with Xen and VMWare. It's difficult to
compete with thousands of men-hours paid by corporate funding.
So far nobody has expressed interest in vkernels as a tool for kernel
development. And I got the general impression that I've proposed
something stupid and useless.
I can see the value in having a virtualisation solution in the base
system that allows one to easily try out kernel development. I know it
would have helped _me_ get into the forbidden land.
I'm augmenting my project idea by dropping the AMD64 version, and adding
"performance work to reduce overhead for disk I/O and networking". I'll
also make sure that no kernel function renaming will be needed, through
some linking magic.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
