Slashdot Mirror
Virtualization In Linux Kernel 2.6.20
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."
For 2.6.19, there's only been a single patch so far (2.6.19.1). Usually there are more. Was 2.16.19 unusually unproblematic, or has attention been drawn away by the development of new features for 2.6.20?
Cutting right to the chase here, if I have this new kernel, and a CPU that supports it (only the latest generation from Intel and AMD do), I should be able to install Windows XP as a guest OS and run it in a window on my Linux machine? That would be very cool and could really help the adoption of Linux. I know I can do something like this with VMWare right now, but if it's built in to the kernel that would be even better. And yes I would have to buy a new machine with one of these current-generation CPUs to be able to do that, but it's worth it to get that anyway.
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!
Couldn't they just try to use a different acronym, how about KbVM?
So... we can compare Xen and KVM to Qemu now? The next time nVidia updates their drivers we should benchmark them against MESA OpenGL...
Xen amd KVM utilize (require, if I remember correctly) support for virtualization-specific processor instructions. Qemu does not.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Okay, I read the charts wrong because I'm apparently an idiot. Native times are the first bar in each graph.
Though VMWare would still have been nice...
Does the dec 12th story make this one a dupe or was just early warning ?
Quidquid latine dictum sit, altum videtur
they can virtualize XP under linux, can have hardware graphics acceleration, and full dx9+ support.
VMWare will perform *much* better on any workload with heavy process thrashing, especially forking (such as the lame compilation or anything that does an autoconf configure and make). This is due to the Intel and AMD virtualization extensions not going far enough to handle unix style OS workloads well (hardware assisted MMU and/or TLB virtualization support is lacking). Context switching takes a heavy toll. Windows doesn't do it so much so it won't suffer as much.
Also, only AMD's SVM supports full-virtualization of x86_64. Intel doesn't implement that.
VMWare works by dynamically scanning/translating native x86 and x86_64 code for protected instructions before executing it so it does not need the hardware extensions to work. That also means vmware performs better by not using the new cpu features.
A I understand it kvm makes use of the VT instructions present in modern CPUs to make QEMU nice and zippy. Older CPUs don't have those instructions so they would still "need" kqemu to make QEMU go full speed.
> [T]he Linux 2.6.20 kernel will include a full virtualization (not para-virtualization) solution. Yep. But Molnár Ingo (yes, the hungarian kernel hacker) Ingo Molnar announced a new patch introducing paravirtualization support for KVM.
3 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 khelper
6 ? 00:00:00 kthread
8 ? 00:00:00 kblockd/0
9 ? 00:00:00 kacpid
102 ? 00:00:00 kseriod
105 ? 00:00:00 khubd
176 ? 00:00:00 kswapd0
784 ? 00:00:00 kpsmoused
814 ? 00:00:00 khpsbpkt
818 ? 00:00:00 knodemgrd_0
seems to fit in with the naming convention of all the kernel related processes.
...and that is all I have to say about that.
http://jessta.id.au
Comment removed based on user account deletion
This is likely to boost QEMU's popularity, the virtualizer accelerated by KVM. An interesting coïncidence is that I released the very first version of Qemudo on Jan 4th while being totally unaware of the existence of KVM. Then three days later the KVM project released their first version too, and I read about it on this kerneltrap article.
I am thrilled at the idea of using KVM + QEMU + Qemudo together. To put it simply, and to quote my README, Qemudo is "a Web interface to QEMU offering a way for users to access and control multiple virtual machines running on one or more remote physical machines." Qemudo makes use of two important features in QEMU: native support of VNC, and copy-on-write disk images for instantaneous VM creation. If you are interested go check out the website (and download the tarball which contains more detailled doc). </shameless-plug>
I feel your pain, deeply! A stable API / ABI is absolutely vital for ISV support and the new development model means that you can only get this if you're prepared to pay a large amount of money for your distribution. I don't want to have to pay $1500 for RHEL, but that's the only way I can run an Oracle dev server on a quad box with 16GB ram. The amusing thing is that RHEL is the ONLY piece of software I have to pay for on that machine - our site license gives us free licenses for dev and DR :)
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!
Benchmarks in the article shows that it is slower than XEN.
Do you know why?
Xen requires some support from virtualized operating system, what about KVM?
On Linux it's easy to tell if you have VT..
/proc/cpuinfo
/proc/cpuinfo
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.
Why do they document the model of CD-ROM drive they used, but not the configuration of each emulation/simulation environment? I was shocked by the LAME compile times--and forced to wonder and guess what the filesystem configuration was. Is the filesystem located in an image file on the "host" computer's filesystem? Wouldn't it be interesting to try using a comparible medium across all benchmarks (shared NFS server, or low-level access to the same block device)?
Not enough data (CPU time vs. real time, etc.), not enough benchmarks (different filesystem media, etc.), poor documentation (configuration, anyone?), on what doesn't even amount to an official release. Correct me if I'm wrong.
Does anybody still have an IDE tape drive that hasn't died of old age? Is is actually big enough to do a backup?
The IDE-SCSI abomination is a foul and evil hack that should have been removed many years ago. Back in the early days, it was needed for CD burning. Linux no longer requires IDE-SCSI. If the cdrecord author told you otherwise... well, he was lying because he damn well knows this isn't true.
Your "fundamental APIs" are not APIs at all. They are kernel-internal details. Screwing around with unmaintained out-of-tree drivers is really not supported, and will never be supported. Go use Windows Vista if you want that... no, wait, Microsoft breaks stuff too! I guess you'll have to live in a fantasy world.
See unistd.h for the stable API. Combined with the SVR4 ELF specification, that gives you a stable ABI. It's been a damn long time since Linux lost an old system call. Old a.out binaries from a dozen years ago still run fine. BTW, outside the kernel even glibc is doing well; the biggest problem has been the C++ library, mainly because the C++ committee kept adding features.
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.
Charles Wyble System Engineer