KVM, QEMU, and kernel project management
Posted Mar 23, 2010 20:45 UTC (Tue) by drag
Parent article: KVM, QEMU, and kernel project management
[b]It's a fact that virtualization is happening in the data center, not on the desktop. You think
a kvm GUI can become a killer application? fine, write one. You don't need any consent from
me as kvm maintainer (if patches are needed to kvm that improve the desktop experience, I'll
accept them, though they'll have to pass my unreasonable microkernelish filters). If you're
right then the desktop kvm GUI will be a huge hit with zillions of developers and people will
drop Windows and switch to Linux just to use it.[/b]
HA! YOUR WRONG!
Completely and totally 150% _WRONG_. So F-ing wrong you should be slapped. :-)
Virtualization on the desktop is absolutely and 100% critical. Absolutely freaking fantastic. The
reason it has not caught on is because virtualization is such a pain in the ass and desktop
market is extremely slow to change.
Your not seeing wide-spread adoption of KVM _right_now_ because KVM requires hardware
extensions to run correctly and Intel makes it a bitch to find the correct combination of CPU
and motherboards to get the most out of it. But that is a purely _temporary_ situation.
Eventually even the cheapest of the cheapest computers are going to have VT extensions in
KVM is a HUGE advantage for Linux becasue support is built in automatically. No drivers to
install, no nothing to configure. Install Qemu-KVM and _your_done_. Eventhing else, in
For example... Integrate x86 hardware with Linux-KVM will unleash a HUGE untapped market.
Something people can buy and just slap into their network.
Windows XP applications?
There are a shitload of those legacy things floating around and around the business market.
Mission critical applications, even built on shit-grade systems, are still mission critical
applications and they are not going to go anywere simply because the hardware turned to
A few examples:
Q: Xen + Citrix.... why?
Q: Quemerant + KVM + SPICE protocol... why?
Q: Vmware purchasing Tungstan graphics and being principal developer/contributer to
Q: Windows Vista and Windows 7's 'XP MODE'... why?
Q: Parrellels insanely popular on Mac... why?
Q: Vmware Workstation, Vmware Player, Vmware etc etc... Why?
Probably 90% of the virtualization solutions out there in proprietary-land are specifically
designed and created with the expressed purpose of solving desktop issues people are
having. Sure much of the big money is going to huge corporate-level solutions like Xen/Citrix
desktop stuff, but that is just because that is were the big money is at.
I mean, seriously, look at all the years of f-king work that went into things like Wine. Years and
years and years of effort to create a open source win32 implementation that can run on
Well I can take KVM and in twenty minutes get something on my Linux desktop that will blow
Wine away in terms of performance (except graphical) and compatibility with not only ancient
Win16/win32 versions, but the most modern stuff Microsoft is coming out with.
And you don't think that is remarkable or important for the success of 'Desktop Linux'. It's not
only important, lack of decent desktop integration is a deal breaker.
As far as Virtualbox goes....
Do you have any idea who owns it? Sun Microsystems (now Oracle)
Is it any wonder why there is no contibuters?!!
They are still following the shitastic "open source core" + "proprietary add-ons" that worked
out so well for tools like Pre-Novell Yast.
Virtualbox is not getting love because they are doing a hybrid open source/closed source
development model PLUS they are owned by Sun Microsystems. That is the reason for lack
of contributions, not because of lack of demand.
I bet that 70-80% the people on LWN run some form of virtualization on their desktops for one
thing or another.
The biggest problem for Qemu is that there is no decent desktop support in the actual Qemu
project. These add-on solutions like 'Qemuctl' or 'Libvirt/virt-manager' are just shit on the
desktop because you cannot make silk out of a pig's ear no matter how many layers of code
you want to place over it. Qemu's problems are absolutely solvable, but they need to be
solved by Qemu.
Things like better sound devices, better USB device support, vastly more user friendly Qemu-
monitor, vastly better graphics performances and acceleration options are going to have to
be tackled on the Qemu side of things in the Qemu code base. The GUI can be seperate, to
be sure, but the GUI and Qemu need to be developed together.
And moving Qemu into the kernel sounds pretty dumb, btw.
to post comments)