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?
Why no comparison against VMWare or native?
(VMWare I can kind of see, if they were deliberately sticking to all free solutions, but no comparison to running on the host system? That's just bad reporting IMO.)
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...
is it no longer required to get full speed out of qemu then?
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
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.
Its about time, this was a long time comming. The next step is to build in some binary translation. Any volunteers.
Founder of the PS3 PhD Project (www.ps3p
I'm wondering what effect this will have on paralell computing / clustering.
"Ubuntu" - an African word meaning "Slackware is too hard for me."
> [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.
I don't like the name... KVM makes it sound like it's part of KDE, when it is not. SVM (Sun virtual machine would be better, IMO)
"It is a denial of justice not to stretch out a helping hand to the fallen; that is the common right of humanity."
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>
Hah, I can handle 16 machines on one piece of hardware.
Trying to become famous by taking photos. Visit my homepage please.
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!
And the reasons you cite above are some of them. People think Pat and the team are stuck in the past but he probably has a better handle on how linux kernel dev has gone down the toilet with 2.6 than many people.
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?
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.
Its amazing but it seems to me as if every plan adopted by the kernel dev. team always falls into the description in the topic.. Right now I agree that the whole concept has evolved right into that which they tried to avoid in the early days. Namely: a massive and sluggish machinery which isn't open to sensible comments and outside input and basicly works under the rule: "We know best". Disclaimer: This is fully from my personal point of view. I'm not claiming to be right, but it sure as hell seems this way to me.
Why? Well, for starters, we have the combined kernel tree. Developing in the kernel; people can claim how this is working all they want but when looking at the results I see a completely different picture. Basicly an enormous overhead for anyone who is trying to maintain a kernel (maintenance is no longer done by the kernel dev. team but but bestowed onto others). A lot of people warned for this to happen but did agree that you wouldn't know untill you tried. Now we're nearing the point of no return; you can see that some people can no longer cope and as such start to either combine their work (fedora), planning to stop their consumer work (more overhead for free is basicly a loss for a company) or simply move onto other platforms. But still; no one is listening... Eventually they will, but I sure hope its not too late then.
Why do I think so? Because I also think that the kernel dev. team is very busy to try reinventing the wheel. Virtualisation in the kernel? I for one recall having played with User Mode Linux. Granted: it was sluggish but with the SKA patch started to run pretty decently. All it really needed was more native kernel support in a good way. But we all know what happened here: basicly a massive wall was formed (once again: in my experience) thus disallowing the original author to develop his baby to its full potential. Finally a small part actually made it into the kernel, but naturally it was broken and you STILL needed to patch it with a 3rd party patch to make it work to its full potential. And ofcourse the SKA patch without which this wouldn't run that well.
Wouldn't it have made more sense to actually spend more time to make Usermode linux more adaptive and allow it to be implemented into the kernel in a native way? A lot of users cried out for this but the kernel dev. team, in their wisdom or sheer arrogance, never bothered with this. And now, several years later, what do we see? Plans for implementing virtualisation in the kernel? Too little too late boys!
Right now I can see what this project (usermode linux) might have become when looking at Sun Solaris and its virtualisation support. Its pretty neat: basicly a Solaris environment running on top of the host in a shielded way. It does utilize the same kernel, but because of the RBAC model (and other ways of securing the OS) this doesn't have to be a security hazzard IF used correctly. Linux has SELinux which has enough potential to help with that, and when it comes to running Linux on Linux there is Usermode linux...
So pardon me while I laugh it out a little.. IMO this really is too little too late and they have only their own arrogance to thank for it. Meanwhile my attention has already been sucked into Solaris and OpenSolaris and I for one don't plan to look back anymore. Keep it up!
The real problem is, of course, the braindead x86 ISA that won't support full self-virtualization without special "extensions".
The 68K family was fully virtualizable back in the late '80s (from the 68020 on).
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
2.6.20 will be the first real release of KVM. This benchmark used 2.6.20-rc3. For 2.6.20-rc4, a new shadow paging implementation was introduced (memory virtualization) that is significantly faster than what was present in -rc3. I've only got microbenchmarks handy, but context switch time, for instance, improved by about 300%.
I suspect if they reran their benchmarks with -rc4, the KVM numbers would be much more competitive with the Xen numbers (although I do suspect Xen will still be on top--slightly).
I thought full virtulization required hardware support ala HVM
How does KVM get around this ? What am I missing ?
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.
Linux 1.1.44 is the one to play with.
I think it got renamed to something like linux-1.1.44-do-not-use on the FTP site.
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.
How?
Asterisk is a real-time process. It expects to wake up 1000 times per second, exactly, on time every time.
Surely you're getting massive drop-out problems.
How does it compare to KVM?
The article says it'll support x86 versions of Windows as guests, but not the 64-bit versions.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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's a fine strategy if newer kernels don't break existing features. But they do because testing is a really hard problem so it doesn't get done well enough.
Some kernel bugs get introduced in x.y.z and don't get resolved until z+4 (or longer!). Depending on the severity, backporting is easier than fixing.
It would be great if this didn't happen so your strategy would always be effective.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Actually, some prefer "random crap" to totalitarianism.
I can't figure out Xen well, so I'd better run for my life. The only thing harder than something in Linux that doesn't give a damn if you can work it (eveything)is something that Linus expects you to understand. A genious, no doubt, but one with no idea that he is trudging over somebody else's product and death will soon follow;)
I'm not too hip with virtualization techniques, so correct me, please. It just seems dangerous to virtualize another, potentially unsecure, operating system within kernel space (isn't that Ring 0?). Does it seem dangerous to anyone else?
What kind of bizzare non sequitur is that? None of the BSD userland tools are part of a totalitarian regime, they are just software.
I have to say, that's the first I've heard of that rule. The Wikipedia definition directly contradicts your statement:
"Acronyms and initialisms are usually pronounced in a way that is distinct from that of the full forms for which they stand: as the names of the individual letters (as in IBM), as a word (as in NATO), or as a combination (as in IUPAC)."
Although anything from Wikipedia should be taken with a grain of salt, that definition sounds good to me.
Look at the size. Well actually, the ad isn't too sure about the difference between MB and GB. Either way, it's not good. Have you looked at hard drive sizes lately?
Look at the price. It's not dirt cheap. Now look back at the size again. Huh? WTF?
Granted, you seem to have found a seller. I guess nobody will buy the remaining stock.
Linux runs on the Altix, which can have up to 2048 CPUs.
That's NOT a cluster. That's SMP, NUMA of course.
It's working now - what about the number of kernels when it WASN'T working because the driver was pulled with almost no notification ?
The real question is where you draw the line between the userland software that is a part of the OS (and thus is subject to a stricter control by the OS developer) and the one that is not.
I don't draw that line, the people creating OSs draw those lines for their OSs. What on earth does this have to do with anything? I just asked a simple question. BSDs already have userlands, they come with shells and all the usual assortment of command line utilities, and package management to add more stuff. What is the point of using the awful GNU/random userland that debian and gentoo subject you to on top of a BSD kernel? There's no need to wait for a debian or gentoo userland to be working nicely on a BSD kernel since each of the BSD kernels comes with a better userland anyways. If you have an answer to that question feel free to speak up, but asking me random questions that have nothing to do with anything isn't clarifying things at all.
OK, to clarify things for you, let it me put it this way: what if I do not want kernel developers to dictate me what userland software to use ("totalitarianism"), what if I want to be able to choose from a myriad of Unix programs that are out there (the ones that you call "random crap").
Is it really true, by the way, that BSD users never use "the awful" GNU software?
Did not think so...
My head asplode! Are you trolling or just really high?
"what if I do not want kernel developers to dictate me what userland software to use ("totalitarianism"),"
How are they supposed to do that? Its your computer, you decide what software to use. No developers (kernel or otherwise) have anything to do with it. Debian provides a userland for you. Gentoo provides a userland for you. FreeBSD provides a userland for you. OpenBSD provides a userland for you. In all of these cases if you don't like any particular piece, you are free to install and use something else. Is debian "totalitarianism" because they give me bash by default? No, I just install ksh and now I have a usable shell. Why would you think it would be any different in any other OS? How are the kernel programmers going to stop you from installing whatever software you want, why would they care to, and why do you think they somehow magically do?
"what if I want to be able to choose from a myriad of Unix programs that are out there (the ones that you call "random crap")."
Then you install them and use them, duh? And I didn't call the myriad of unix programs that are out there "random crap". I called the random crap that fills in the holes in the otherwise totally GNU userland "random crap". Stuff like file, less, ncurses, etc. It wasn't to say that any particular piece of software in that list is crappy, just that its together "random crap". A bunch of unrelated programs all tossed together from different sources.
"Is it really true, by the way, that BSD users never use "the awful" GNU software?"
No, each individual BSD users uses whatever the hell they want, just like each individual user of any other OS. Why do you keep asking weird questions that have nothing to do with anything? Are you trying to win some kind of bizzare non sequitur award? I said nothing about what software BSD users use, I said each BSD already has a userland, so there's no need to wait for debian or gentoo to get their inferior userlands ported to a BSD kernel. BSDs aren't just kernels, they are OSs, they come with userlands already.
Do you like peanut butter and ketchup sandwiches?
Did not think so...
their inferior userlands
Care to give an example of the alledged inferiority/superiority? (Well, you already had to replace the default shell in the otherwise perfect OS.)
I do not think my questions are weird. Well, maybe they are, for those who cannot think consistently:
a BSD kernel. BSDs aren't just kernels
Repeat after me: kernel is one thing, "userland" (I hate the term) is another, they have nothing to do with each other, and so it is perfectly fine to use a BSD (or any other) kernel in gentoo or debian. By the way, my understanding is that the core technical difference between linux distributions lies in their package and configuration management, not in the choice of software (which is pretty much everything under the sun).
I played with FreeBSD back in the 4.x days (not for too long) and found it good, but, as far as I was concerned, not much different from linux; I had a romance with NetBSD for much longer, even done some minor development for it -- and then went back to Slackware, feeling good again exactly because there was virtually no package or configuration management, and my userland consisted primarily of the "random crap" -- programs compiled from sources I downloaded directly from their authors' websites. Pure LFS would serve me better, but Slackware is easier to install; essentally, I have been using it as an LFS though.
One thing that has been making me sick was exactly that supid old song of BSD fanboys about BSD's "superiority" and that it is not a kernel but an OS. So what? Debian is not a kernel either, and, again, why should I care? Why don't y'all change the tune, or, better yet, just shut up.
"Care to give an example of the alledged inferiority/superiority?"
Look at all the gnu utils. They are bloated to twice the size or more of what they should be, full of duplicated, superfluous, non-standard options that make them slower and reduce portablility. Hell, they managed to fuck up tar for crying out loud, using a non-standard gnu extension that causes more problems than it solves. gsed, gawk, bash, fileutils, info especially. Its all bloated crap.
"I do not think my questions are weird. Well, maybe they are, for those who cannot think consistently:"
They are definately weird, because you are not thinking consistantly. I simply stated that each BSD already includes are userland, so the original poster has no need to wait for a debian or gentoo userland. You responded with bizzare questions about totalitarianism and kernel developers stopping you from running software, neither of which are relevant or make any sense.
"Repeat after me: kernel is one thing, "userland" (I hate the term) is another, they have nothing to do with each other, and so it is perfectly fine to use a BSD (or any other) kernel in gentoo or debian"
What are you smoking? There is nothing wrong with the term userland, kernels and userlands do have something to do with each other when they are developed together and/or specifically for each other (e2fsprogs kinda goes with the linux kernel don't you think?). It is perfectly fine to use a BSD kernel in gentoo or debian, but its also completely stupid and there's no need for it. If someone wants to not use linux, they can just use a BSD or solaris right now, they already have their own userlands, you don't need to wait for someone to get a debian or gentoo userland running on a BSD or solaris kernel.
"and then went back to Slackware, feeling good again exactly because there was virtually no package or configuration management, and my userland consisted primarily of the "random crap" -- programs compiled from sources I downloaded directly from their authors' websites."
You really are a dumbass aren't you? Slackware has package management, and it forces a default userland on you. If you choose to install random stuff from source for no reason, that's up to you. But you can do that just as well on any other linux distro, or a BSD, or solaris. Having package managment doesn't force you to use it obviously, since slackware has package management.
"One thing that has been making me sick was exactly that supid old song of BSD fanboys about BSD's "superiority" and that it is not a kernel but an OS. So what? Debian is not a kernel either, and, again, why should I care? Why don't y'all change the tune, or, better yet, just shut up."
If it makes you sick, then why are you so obsessed with it, and why are you pretending it has anything to do with me? I didn't say any given BSD is better than any thing else because its an OS. Debian and gentoo are also OSs, that doesn't even make sense. You really should quit making up stuff that makes you sick.