I think the Luvalley architecture is fascinating but one of the larger
problems that has always been faced by the Open Source Community has
been lack of device driver support for all of the many peripherals and
motherboards and bits of hardware out there.
This is the problem with "bare metal" hypervisors, we see exactly the
same problem with commercial use of the ESXi "bare metal" hypervisor -
limited device driver support - and the worst, being disk driver
support. ESXi, being based on Linux, has no
good support for SATA-raid (ie: poor mans pseudo RAID 0 ) FreeBSD
by contrast, has excellent support, far better than Linux.
The practical reality of it is I can go out and buy a brand new,
super-fast computer and run FreeBSD 8 on it then VirtualBox on that,
then my guest OS's under VirtualBox - and get the same performance
as a bare-metal hypervisor like ESXi or Luvalley on older hardware.
And, with the FreeBSD/VirtualBox way, I get access to a far wider array
of hardware including disk RAID hardware.
Thus, I have to say that I feel the bare-metal hypervisor approach
is a dead-end. Yes, I realize ESX has made a lot of money with this
approach but the newest hardware coming on the scene is incredibly
fast. Even if you put pseudo raid support into luvalley, your never
going to get the kind of hardware support that you can get from
an operating system that is used for far many more things than
just virtualization.
Ted
On 1/9/2011 5:57 AM, Xiaodong Yi wrote:
Yes, license is a big problem. And I'm sorry to let you and Brandon
know that Luvalley is currently using KVM's code. And I think it's
hard and unnecessary to write the virtualization code from scratch. Do
you think so?
Best regards,
Xiaodong
2011/1/9 Juergen Lock<n...@jelal.kn-bremen.de>:
On Sun, Jan 09, 2011 at 12:33:59AM -0600, Brandon Gooch wrote:
On Sun, Jan 9, 2011 at 12:01 AM, Xiaodong Yi<xdong...@gmail.com> wrote:
Hi,
I confirm that I no longer have time for Luvalley. However, I will be
extreemly happy if anybody is willing to take over from me.
Especially, I quite agree to customize Luvalley for FreeBSD, through
it supports all kinds of Dom0 OSes. Howerver, I hope that the LIGHT
architecture of Luvalley could be kept. Maybe it is useful to patch
dom0 FreeBSD kernel (especially for interrupt handling), but it should
not be very complex. Part of the code comes from KVM, and I suggest to
keep flying with KVM to make sure that guest VMs work well.
I believe that if serious effort were to be put forward by the FreeBSD
developers to further develop the code, the result would need to be
GPL and Linux free (or VERY close to it). This is an area of
contention within the FreeBSD developer and user community, so it
would need to be addressed. As the developer of Luvalley, do you have
the ability to re-license the code using a BSD license?
Are there too many technical issues with the code to do this? Juergen
mentioned that bits of the code are based on (or pulled directly
from?) Linux KVM. That probably wouldn't fly here...
Luvalley does boot and run on bare hardware. But it does not taint
dom0 FreeBSD. Although the `non-root' mode dom0 FreeBSD kernel has
direct access to BIOS and hardware, Luvalley tries hard to coordinate
with it. For example, Luvalley traps the BIOS calls from the FreeBSD
kernel to report the modified E820 table. Another example is that
Luvalley uses NMI as the IPI interrupt to avoid conflict with BSD
kernel. And I also believe that simple patches could work if some
corners of FreeBSD kernel are tainted.
Regards, and looking forward to the following news ...
Xiaodong
As am I...
Thanks for chiming in Xiaodong!
Actually with `tainting' the FreeBSD kernel I meant causing it to be
affected by the gpl and its requirements. So if someone were to ship
e.g. an appliance that uses Luvalley and a modified FreeBSD kernel he
would only have to provide sourcecode of Luvalley and the userland
Luvalley version of qemu-kvm, not of his FreeBSD kernel modifications,
or of other (non-gpl) userland apps for that matter.
But again, IANAL. :)
Cheers,
Juergen (also hoping Luvalley will have a future...)
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
