Virtualization In Linux Kernel 2.6.20 178
mcalwell writes with an article about the Kernel-based Virtual Machine (or KVM for short) in the release candidate Linux 2.6.20 kernel. From the article: "[T]he Linux 2.6.20 kernel will include a full virtualization (not para-virtualization) solution. [KVM] is a GPL software project that has been developed and sponsored by Qumranet. In this article we are offering a brief overview of the KVM for Linux as well as offering up in-house performance numbers as we compare KVM to other virtualization solutions such as QEMU Accelerator and Xen."
Simple Q: will this run Win XP as a guest? (Score:2, Insightful)
At the same time, we have Wine making great progress and able to run a whole bunch of useful Windows apps without even needing any virtualization, so Linux is soon going to assimilate everything!
Acronym overload (Score:5, Insightful)
Mod me down! (Score:2, Insightful)
Though VMWare would still have been nice...
Call me when... (Score:2, Insightful)
Re:Oddness in kernel release cycle (Score:5, Insightful)
Mod... Parent... Up (Score:5, Insightful)
Anyone other than SLES or RHEL is a second class Linux citizen today. Without vendor support you can forget about trying to run a stable Linux kernel anymore. Bring back the old odd / even split!
Re:kqemu? (Score:3, Insightful)
egrep '^flags.*(vmx|svm)'
if that returns anything you have VT, if it doesn't, you don't.
Here's what I get on my desktop (Intel Core 2 Duo).
alan@wopr:~$ egrep '^flags.*(vmx|svm)'
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
There is a list on the Wikipedia page (http://en.wikipedia.org/wiki/X86_virtualization) of supported chips.
Re:Mod... Parent... Up (Score:5, Insightful)
The patches that each comes up with the backport specific security features will be different, if only slightly. The patches that each comes up with to backport a highly requested feature will be slightly different. Over time these slight differences will add up to become real differences between the distros.
Distros should NEVER backport features. That's the whole point of the new development system. If you want a stable kernel stay with the point release your on and just add the security/stabillity patches. If you want new features use a newer kernel.
That right there was the exact problem with the old even/odd split. The time between the two ended up being so great that people/vendors would start backporting features and destabilizing the "stable series" kernel.
Distros forking the kernel has always been an annoyance so it's nothing new either. I've been playing the "wich distro has the drivers I need" game since 2.0.x and it got to the point where I just never use distro kernels anymore I just compile my own and add that to the installer.
Re:Call me when... (Score:3, Insightful)
quit your FUD, it's getting old (Score:5, Insightful)
I think your real complaint is that out-of-tree drivers are unsupported. Tough luck. This will never change. I suggest that you get your drivers into the tree, where other people can review them for bugs (afraid of that? embarrased?) and update them as the rest of the kernel changes.
Re:Multicomputing (Score:2, Insightful)