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?
For only being a release candidate the Linux 2.6.20 kernel has already generated quite a bit of attention. On top of adding asynchronous SCSI scanning, multi-threaded USB probing, and many driver updates, the Linux 2.6.20 kernel will include a full virtualization (not para-virtualization) solution. Kernel-based Virtual Machine (or KVM for short) is a GPL software project that has been developed and sponsored by Qumranet. In this article we are offering a brief overview of the Kernel-based Virtual Machine 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.
What has been merged into the Linux 2.6.20 kernel is the device driver for managing the virtualization hardware. The other component that comprises KVM is the user-space program, which is a modified version of QEMU. Kernel-based Virtual Machine for Linux uses Intel Virtualization Technology (VT) and AMD Secure Virtual Machine (SVM/AMD-V) for hardware virtualization support. With that said, one of the presented hardware requirements to use KVM is an x86 processor with either of these technologies. The respective technologies are present in the Intel Core series and later, Xeon 5000 series and later, Xeon LV series, and AMD's Socket F and AM2 processors.
The Kernel-based Virtual Machine also assigns every virtual machine as a regular Linux process handled by the Linux scheduler by adding a guest mode execution. With the virtual machine being a standard Linux process, all standard process management tools can be used. The KVM kernel component is embedded into Linux 2.6.20-rc1 kernels and newer, but the KVM module can be built on older kernels (2.6.16 to 2.6.19) as well. At this stage, KVM supports Intel hosts, AMD hosts, Linux guests (x86 and x86_64), Windows guests (x86), SMP hosts, and non-live migration of guests. However, still being worked on is optimized MMU virtualization, live migration, and SMP guests. Microsoft Windows x64 does not work with KVM at this time.
Whether you are using a kernel with KVM built-in or loading it as a module, the process for setting up and running guest operating systems is quite easy. After setting up an image (qemu-img will work with KVM) and the KVM kernel component loaded, the modified version of QEMU can be used with the standard QEMU arguments to get you running.
The hardware requirements to use KVM is an x86/x86_64 processor with AMD or Intel virtualization extensions and at least one Gigabyte of system memory to allow for enough RAM for the guest operating system. For our purposes, we had used two dual-core Intel Xeon LV processors with the Linux 2.6.20-rc3 kernel, which was released on January 1, 2007. Below is the rundown of system components used.
Hardware Components
Processor: 2 x Intel Xeon LV Dual-Core 2.00GHz
Motherboard: Tyan Tiger i7520SD S5365
Memory: 2 x 512MB Mushkin ECC Reg DDR2-533
Graphics Card: NVIDIA GeForce FX5200 128MB PCI
Hard Drives: Western Digital 160GB SATA2
Optical Drives: Lite-On 16x DVD-ROM
Cooling: 2 x Dynatron Socket 479 HSFs
Case: SilverStone Lascala LC20
Power Supply: SilverStone Strider 560W
Software Components
CmdrTaco Penis: Very small and covered with herpes sores.
Operating System: Fedora Core 6
The benchmarks we had used for comparing the performance was Gzip compression, LAME compilation, LAME encoding, and RAMspeed. The virtualization environments we had used were QEMU 0.8.2 with the kqemu accelerator module, Xen 3.0.3, and finally KVM. We had also compared these virtualized environments against running Fedora Core 6 Zod without any form of virtualization. During the Xen 3.0.3 testing, we had used full virtualization and not para-virtualization. The image size was set to 10GB during the testing process. The operating system used throughout the entire testing process was Fedora Core 6 Zod.
Looking over the virtualization performance results, K
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?
Kernel schould be good at caching, scheduling (and also excellent choice for access to host hardware - via QEMU layer of course). KVM is based on experience with Xen and paravirt ops, and because skilled hackers are working on it, I expect it to surpass or at least match systems like Xen or VMWare in performance and some features. In future, I believe special schedulers/ managers will be added to kernel for managing VM resources (once KVM matures enough).
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!
Remember that little thing called the gpl?
Yep, basically if you're not happy with the changes that the linux devs have been doing, then fork it and seeing how things are currently, I'm sure the sane linux devs would jump aboard rather quickly.
I agree fully, I used to grab linux kernels for certain things, now I'm glad I use a distro that maintains kernels for me, linux as of late has become a clone of microsoft in all of the bad ways. Linux is becoming broken for the sole reason that someone was too lazy to create a new branch for a new kernel and said "fuck it, people want to play with the unstable code, so let's pollute the stable tree with buggy code!"
I recently had trouble compiling a new kernel source because of inane errors, when I asked about this, I was given the prompt "go fuck yourself"
When did this attitude start? when I started using linux, everything was set apart neatly, you knew the kernel you were downloading was stable and that anything wrong would be remedied, and no unstable code was in the fresh tree. I see why some people have chosen to stick with 2.4 (though it only works great if you dont use a desktop with modern features..)
Seriously, this is embarrassing, now microsoft CAN call linux out for being no better.
I pray someone with some coding skills will actually try to fork the kernel and organize it in a sane and stable manner, whilst keeping compatibility.
It's kind of hard to think of, but considering Xfree86 is now fading into obscurity after being dethroned roughly 2 years ago by xorg, which created a friendlier, more active, and sane fork, I see something like a linux fork not being a far fetched idea. It's bound to attract some developers from the main source, possibly.
Why would you want the horrible mess of GNU bloatware and random crap that is a debian or gentoo userland? Just try one of the BSDs, they have much nicer userlands already on their own, no need for Debian/ or Gentoo/ at all.
You can seriously get into universities in the US without grasping the basics of 3rd grade english?
come -> coming
shame -> shaming
hum -> humming
dim -> dimming
Notice a pattern there? This isn't fucking complicated, my 8 year old manages just fine.
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)
Kernels from 2.6.9 onwards are a disaster.
Oh, it's just like Star Trek!
You can use the odd/even rule to determine quality up until a certain point, and then they all suck.
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;)
my phillips webcam is working fine under 2.6.18
/dev/video0.
:)
The webcam is actually quite old..
I just plugged it in just to be sure:
Linux video capture interface: v2.00
pwc: Philips webcam module version 10.0.12 loaded.
pwc: Supports Philips PCA645/646, PCVC675/680/690, PCVC720[40]/730/740/750 & PCVC830/840.
pwc: Also supports the Askey VC010, various Logitech Quickcams, Samsung MPC-C10 and MPC-C30,
pwc: the Creative WebCam 5 & Pro Ex, SOTEC Afina Eye and Visionite VCS-UC300 and VCS-UM100.
usbcore: registered new driver Philips webcam
usb 1-1: new full speed USB device using uhci_hcd and address 3
usb 1-1: new device found, idVendor=046d, idProduct=08b0
usb 1-1: new device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: configuration #1 chosen from 1 choice
pwc: Logitech QuickCam Pro 3000 USB webcam detected.
pwc: Registered as
usbcore: registered new driver snd-usb-audio
And yes, i can see a picture, too
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?
Here in Germany everything post-sale (most EULAS are that) is completely irrelevant and judges have always without any doubt ruled in this spirit, the law is quite clear in that respect.
Besides that, if i buy Software from a shop i have made a contract of sale with the shop AND WITH NO ONE ELSE and have in NO WAY closed any contracts with the softwares original manufacturerm, so there is no idea of such a thing as a software license from the manufacturer.
EULAS are only valid (in Germany) if you see and accept them before sale, for example if you buy online and download the program and had to read and accept the eula BEFORE YOU PAID.
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.