Qumranet de-cloaks

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:
$ /sbin/fdisk -lu good.img
You must set cylinders.
You can do this from the extra functions menu.

Disk good.img: 0 MB, 0 bytes
16 heads, 62 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xe6f7f6f6

Device Boot Start End Blocks Id System
good.img1 1 207327 103663+ 83 Linux
good.img2 207328 289663 41168 83 Linux
good.img3 289664 1000927 355632 83 Linux

(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....
apt-get install module-assistant qemu qemu-launcher
m-a update
m-a prepare
m-a a-i kqemu

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.