kqemu mode not compiled for karmic

Thanks for the report. We've gotten a few requests about this over the last few weeks. I need to respond to all of those here.

Upstream QEMU has configured kqemu off by default for 0.11, and has completely removed the code from the tree for 0.12. This is upstream's acknowledgement that kqemu is simply unsupportable.

We, Ubuntu, could conceivably ./configure --enable-kqemu for the qemu-kvm-0.11 package in Karmic, however, this would introduce (as I see it) two serious problems...

 1) We would be shipping code (in main nonetheless) that upstream is consciously and vocally refusing to support. I think this unwise, at best. We wouldn't get any help fixing/supporting issues (even security vulnerabilities) that come up.

 2) And more importantly, enabling kqemu has a *detrimental* effect on ALL Ubuntu KVM users... Enabling kqemu limits the amount of physical memory to VM guests to ~3.5GB. This is something I feel strongly about. Karmic will be around for another 1.5 years, in which we can expect hosts memory to double (at least).

I am very open to the possibility of a community maintained qemu-kvm (+kqemu) package in the ubuntu-virt PPA.

:-Dustin

Can we have two packages.
One that works with CPUs that support kvm, and one that works with CPUs that do not support kvm, e.g. with kqemu instead.
I think it is sensible to assume that all new CPUs will support kvm, so that handles the physical memory >3.5GB issue.
But, for older CPUs, that do not support kvm, we need an VM that actually functions.
For example, running the ubuntu version of kvm on a machine that does not support kvm, results in kvm running in normal qemu mode, but this has bugs and fails to run when used with 32bit host, and 32bit guest.
One gets "no vm86_info: BAD" messages
The original qemu without the kvm patches, works correctly.
I have talked to kvm developers and they will not be fixing bugs in the non-kvm code paths, but qemu developers will be fixing bugs in the non-kvm path. Apparently, there are kvm patches that break the non-kvm code paths.
So, can we please have two packages, one from the kvm tree, and one from the qemu tree.

About half of Intel's Core 2 Duo processor models shipping today do _not_ support KVM, much less lower end processors like Celeron, Atom, etc.. There are quite reasons to run qemu on such lower-spec'd machines.

If kqemu support is disabled in karmic, why are the kqemu-source and kqemu-common packages available in the karmic repositories ?

I agree with Traumflug's comments - there are MANY multicore processors shipping today that do not support KVM, plus of course, all of the lower end processors.

The removal of kqemu support is not even mentioned in the Karmic Release Notes !!

Shht. The kqemu packages still work great in combination with qemu built from source.

Perhaps the way froward is to make qemu-source a dependency of the kqemu packages

I've compiled qemu from source, but when I try to use it with kqemu, I get the following error:

/usr/bin/qemu: invalid option -- '-domid'

Current situation is unbearable for all the users of Intel multicore CPUs that do not have VT, i.e. half of them. kqemu provided quite decent performance with those CPUs, but without kqemu performance drops dramatically !!!

> /usr/bin/qemu: invalid option -- '-domid'

That's odd, as qemu doesn't have a feature "domid". Even the
unavailable options are listed with "qemu -help".

Are you sure to use the newly compiled qemu? "which qemu" will tell you.

Which sources are you using? I'm using the plain sources from
www.qemu.org. By default, they install into /usr/local and the
resulting binary lives in peace along with the one from the Ubuntu
package.

>> /usr/bin/qemu: invalid option -- '-domid'
>
>That's odd, as qemu doesn't have a feature "domid". Even the
>unavailable options are listed with "qemu -help".
>
>Are you sure to use the newly compiled qemu? "which qemu" will tell you.
>
>Which sources are you using? I'm using the plain sources from
>www.qemu.org. By default, they install into /usr/local and the
>resulting binary lives in peace along with the one from the Ubuntu
>package.
>

I'm using the latest sources from the Qemu site.

The problem occurs when I'm using virt-manager or virsh to run the Virtual Machines under kqemu.

It worked fine under hardy,intrepid, and jaunty.

Am 28.10.2009 um 18:21 schrieb Nigel Pallett:

> The problem occurs when I'm using virt-manager or virsh to run the
> Virtual Machines under kqemu.

I can't help here as I use qemu without any "managers". Typical
strategy here is to try find out which commands these managers try to
launch and to re-try them in the command line. Likely not a qemu
issue, though, as those manager should do what qemu accepts, not the
other way around.

I'm agree with Julien Aubin, please provide a package of qemu with kqemu enabled for everyone.

* PauLoX wrote, On 08/11/09 12:22:
> I'm agree with Julien Aubin, please provide a package of qemu with kqemu
> enabled for everyone.

Please allow launchpad to accept bounty offers so users can influence
and contribute to the fixing of bugs.

Sam

Yep, I too have a new ASUS U50V laptop with Intel Dual Core but no VT and now no kqemu. I have either compile from source or use non-open source alternatives. It would be better if qemu could support ordinary CPUs like before.

I can only point you to VirtualBox for non-VT virtualization in ubuntu. I'm sorry.

Yes, VirtualBox provides fairly decent performance for non-VT CPUs, almost the equivalent to kqemu. If your guest is a Windows XP machine, ensure you deactivate the ACPI in the VirtualBox launch parameters, and then you'll have to reactivate your Windows XP.

Prior to doing that, you have to convert your qemu image to a VMDK image, which is supported by virtual box, using tool qemu-img