| |||||||||||||
|
| |||||||||||||
Qumranet de-cloaksQumranet de-cloaksPosted Sep 25, 2007 20:46 UTC (Tue) by khim (subscriber, #9252)In reply to: Qumranet de-cloaks by subhashreddy52 Parent article: Qumranet de-cloaks
Short explanation is simple. There are exist a problem with virtualization: classic x86 is hard to virtualize since some privileged commands just return wrong result when called in unprivileged mode Iinstead of causing catchable exception) and so can not be properly virtualized. VMWare, Xen and KVM differ in approach to solve this problem. VMWare is doing on-the-fly binary recompilation - which usually works very well, but now and then everything just blows up. Xen is using modified kernel sources - so offending commands are not used at all. KVM uses hardware solution: Intel VT and AMD-V offer a way to virtualize these "bad" conmmands. Now it should be easy to see why the KVM is the only sane solution - and also why it's so immature right now: support for virtualization in hardware is a new thing, before it existed KVM was unimaginable so all code is new. VMWare and Xen are working solutions but actually without feature - or rather their future is slow conversion to "KVM-style" over many years.
(Log in to post comments)
Qumranet de-cloaks Posted Sep 26, 2007 12:21 UTC (Wed) by cpm (guest, #3554) [Link] Thanks very much for that concise explaination. I've been sufferingthrough stuff written as it were important to avoid actually explaining anything.
Qumranet de-cloaks Posted Sep 26, 2007 15:21 UTC (Wed) by pcampe (subscriber, #28223) [Link] VmWare and Xen also offers hardware-assisted virtualization, so they are more pervasive than KVM. As the whole point about virtualization is having an homogenous environment from heterogeneous hardware, they are better because you do not have to buy brand new server to virtualize your current workload.
I agree that some years from now we'll have minimal performance drop in hardware-assisted virtualization, but now and for some time para-virtualization is still better (I don't dig into AMD Barcelona-specific nested-paging that, they say, will help a lot in covering the gap).
Qumranet de-cloaks Posted Sep 27, 2007 18:01 UTC (Thu) by drag (subscriber, #31333) [Link] KVM is Qemu-based, no?
We already have a drop-in for people who do not want new servers.
Kqemu accelerator for Qemu. On the current generation of hardware Xen/KVM/Kqemu offer compariable efficiences when doing full virtualization.
The nice thing is that, right now, you can get virtualization without paying a cent, without adding patches to your kernel, or running it on a hypervisor.
And there is also nice GUIs for managing it. Qemu-launcher works just as well with KVM as it does with Kqemu-accelerated Qemu or just plain Qemu.
Here are just a few of the fun things you can do, right now, with Qemu-based environments.
provide block devices to run as the emulated disk. Much faster then loop-back-file-based virtual drive. This can be done locally by dedicating a partition or, better yet, using software raid and LVM and using logical volumes for drives. This can be done remotely by taking advantage of NBD, iSCSI (open source, high performance, software solutions are Open iSCSI (in the kernel) and iSCSI enterprise target), GFS's GNBD, and probably ATAoE (although, IMO, iSCSI or NBD/GNBD offer better solutions)
You can mount 'partitions' in a partitioned logical volume (or loopback file) by taking advantage of the 'offset' option in mount (and losetup)
For example:
Disk good.img: 0 MB, 0 bytes
Device Boot Start End Blocks Id System
(the -u option has everything show up in 512 byte blocks)
multiply 512 by the 'start' number for and you get your offset to use in the mount command.
So that takes care of (relatively) high performance I/O
Want to have 'headless' virtual servers?
Qemu has the option of connecting a virtual serial port on the hosted OS to the terminal that launched it. So if you configure lilo correctly and configure your console on the hosted OS to output to that serial port then you can have boot prompt access and console access to your sytem. Then with screen running you can go ahead and log out.
Then there are all sorts of other things you can do. It's very cool.
If your using Debian....
The most difficult part is that Debian doesn't set the kqemu module to proper permissions yet (say a kqemu or virtual group or something) so you have to chmod that manually, but it's not a big deal.
On most computers that can run KVM they will still run Kqemu a bit faster. The hardware support just isn't better then software right now. But either way they both can provide a VM that has within 92% the performance of the host cpu performance.
It's to the point were the actual difference in CPU performance is immaterial. What the big bottlenecks are doesn't have much to do with CPU performance, but has much more to do with I/O. Disk I/0, Video output, and network I/O is still MUCH MUCH slower in a VM.
In terms of Linux/FreeBSD/etc we can get OpenGL hardware acceleration over network'd X using AIGLX (I've tried it from Linux host to Linux host and it works great). But now it's possible to get OpenGL acceleration on a desktop running X locally through VMGL. http://www.cs.toronto.edu/~andreslc/xen-gl/
Used to be Xen-GL, but it should work for Qemu-based stuff now also. Should be possible to be used with Windows running in a VM with special windows drivers, but for right now it's *nix only.
If Linux desktop-friendly Qemu-based virtualization efforts (KVM, Kqemu, VirtualBox is also Qemu-based, as is Win4lin (Win4lin paid to get Kqemu released under the GPL, btw)) solve the I/O performance issues then that would definately put Linux and open source on the top of low-to-mid range virtualization market... with high-end enterprise VM going with Xen and Vmware.
I, repeat. The virtual cpu performance differences between Kvm/Kqemu/Xen (non-para-virtualized), and Vmware are negligable. Effectively that is a solved problem when compared to the I/O bottleneck issues.
I suppose Linux will just have to get a special 'virtualization' disk and network driver so that, along with special drivers running in OS in the VM will allow a para-virtualization approach to I/O. Something like that. I think I remember seeing here somewhere people were talking about it.
|
|
||||||||||||