Kernel Virtualization with rdesktop?

drag

Elite Member
Jul 4, 2002
8,708
0
0
_Very_ much faster.

If you have a proccessor that supports either Intel's VT or AMD's SVM extensions you can use KVM.

If you do not have a proccessor that supports it or if you experiance instabilities then you can use KQEMU.

Either way you get within about 80-85% the performance of native hardware.. that is Windows without any emulation.

With Kqemu it's fairly seemless with Qemu. Qemu has support for that built-in. After the normal compile/package install for Linux drivers you have to make sure that you have /dev/kqemu setup with permissions that your user can use. Then if you have recently added yourself to a new group you have to logout and log back in for the changes to take effect. Not sure how it's done exactly with Ubuntu (weither or not Ubuntu sets up a new kqemu group or if they have kernel packages or whatnot), but it's not something that should be very difficult.

KVM is a bit more involved, but I expect that packages are aviable for it also. KVM uses a hacked version of Qemu you that to install (can be side by side with qemu usually) that supports it.

KVM may be a bit faster.

If your using a very latest kernel with 2.6.20 (or later) it would be somewhat faster then Kqemu and both are very much faster then qemu alone.
 

drag

Elite Member
Jul 4, 2002
8,708
0
0
Oh, qemu's ACPI support is somewhat buggy/and or limited that may cause bluescreens during install time. If you have problems then disable acpi and/or disable kqemu/kvm during install time. After install then it's fine to use either usually.

Sometimes the Vesa/Bosch driver can provide better video performance (not a issue if your using rdesktop), and I don't know about which sound card is better. Probably the Esoniq emulation, but I don't know.

For best disk space you want to use 'KQOW' disk image, which only consumes as much real disk space as what you need to contain the files in the emulator.(in other words a 50 gig disk image with 5 gigs of data will only use 5gigs real disk space).

For best performance you want to give Windows it's own disk or partition to run off of. Also if your using Logical Volume Management (LVM) then giving it a logical volume to use as a disk image will give very good disk performance. This will help give your system much better performance then just using a raw image file or qcow file to run out of.

I also suggest checking out FreeDOS to see what the world would be like if DOS wasn't dead. It's pretty highly compatable with those weird DOS drivers and such things and is a nice way to play oldschool games.

Also be sure to allocate lots of RAM.
Qemu by default gives only 128 megs or so, or maybe 256. :)
 

drag

Elite Member
Jul 4, 2002
8,708
0
0
Probably not. Just unaccelerated graphics.

Vmware had a demo a while ago at having emulated 3d acceleration that was good enough to play like old directx 7 (or maybe 8) games. But that seems kinda complicated to the point of not realy being reliable.

Eventually with the PCIe 2.0 specification there should be smarts enough built into the hardware to hand a device over to OS running in a VM, so you could probably do something similar to dual boot, but have it happen very quickly. (like a second or so).
 

xtknight

Elite Member
Oct 15, 2004
12,974
0
71
I thought the Intel VT/AMD Pacifica instructions didn't help speed much, in fact decreased speed? I heard that 2nd gen or 3rd gen VT instructions would be faster.

I tried KQEmu w/ kvm with XP on a Linux host, and honestly VMware still feels faster due to mouse drivers.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
I thought the Intel VT/AMD Pacifica instructions didn't help speed much, in fact decreased speed? I heard that 2nd gen or 3rd gen VT instructions would be faster.

I don't see how the VT instructions could help performance that much either, mostly what they were designed to do is allow guest OSes to run in ring 0 so that you could run unmodified OSes and take a little bit of the management work away from the hypervisor and put it in hardware.