Red Hat Bugzilla – Bug 494286
Unable to boot because libvirt uses '-cpu qemu32' with x86_64 virtual machine
Last modified: 2009-04-06 11:58:55 EDT
Description of problem:
Existing x86_64 virtual machines started using virt-manager do not boot any longer.
Version-Release number of selected component (if applicable):
1. Start a x86_64 QEMU-KVM machine using virt-manager, created before this bug occurred (for me, that was after updating on April 5th).
2. Note the error message above.
Virtual Machine does not boot, and instead presents this error message:
"This kernel requires an x86-64 CPU, but only detected an i686 CPU. Unable to boot -- please use a kernel appropriate for your CPU".
Virtual Machine boots.
/var/log/libvirt/qemu/cobbler.log shows the following:
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -cpu qemu32 -m 512 -smp 1 -name cobbler -uuid c348b19e-0ac3-83e2-91fc-5e9a7316e3b0 -monitor pty -pidfile /var/run/libvirt/qemu//cobbler.pid -boot c -drive file=/data/VMWARE/cobbler-disk0,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:02:58:7e,vlan=0,model=virtio -net tap,fd=17,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us
qemu-kvm -cpu ? gives me the following output:
I'm available for any further testing, troubleshooting or questions. I was not sure if this was a virt-manager or qemu bug, sorry if I filed it on the wrong component. :)
This error does not occur when I install a new machine (in this case using cobbler+koan).
The issue is that libvirt has added '-cpu qemu32' for whatever reason
Could you attach the domain's XML config? i.e. "virsh dumpxml cobbler"
I suspect it has:
<type arch='i686' machine='pc'>hvm</type>
Created attachment 338302 [details]
Erroneous domain XML file
That's indeed the case. This is not the domain Cobbler (needed it for work, recreated it), but my domain test-f10 which had the same problem.
The obvious workaround is to use "virsh edit test-f10" and change i686 to x86_64
(In reply to comment #3)
> That's indeed the case. This is not the domain Cobbler (needed it for work,
> recreated it), but my domain test-f10 which had the same problem.
Can you tell us how exactly you created these domains? The XML is incorrect, so perhaps cobbler/virtinst was getting this wrong in the past?
Mark is correct in that your XML config is requesting a 32-bit CPU.
<type arch='i686' machine='pc'>hvm</type>
Previously this configuration was not actually supported on a 64-bit host - it was never declared in the host capabilities XML as valid - it just happened to 'work' by pure luck, but would have given you a 64-bit guest, not the 32-bit guest it was requested. As of 0.6.2 we now officially support 32-bit KVM guests on 64-bit hosts, and use the '-cpu' arg to make it use a real 32-bit CPU in the guest.
If you have installed a 64-bit OS in this 32-bit guest, then you'll need to use 'virsh edit' to change it to be a 64-bit OS.
I created the domains using Cobbler. Cobbler (more specifically, koan), in turn, uses python-virtinstall.
It seems to me that this was indeed a bug from the past that did not manifest until recently.
Changing the arch to x86_64 using virsh edit worked, thanks.
I'm really curious as to how you came to have arch='i686' in your XML - it would be good to know exactly where the bug was that caused that.
It may have been e.g. that virt-install didn't specify an arch and libvirt's choice of default arch was i686 (i.e. incorrect).
Anyway, the bug was whatever choose arch='i686' - libvirt's current handling of that is correct.
So, closing as NOTABUG for now - if you figure out where the arch='i686' came from, please open a new bug with that information. Thanks.
My guess is that the xml originally had no arch value. This is how virtinst used to build the xml (unless the user manually specified an arch), and libvirt never used to fill it in (since in the qemu driver, it wasn't used for anything).
Recently though libvirt _did_ start filling in this value if none was specified. I think there was also a bug in this area that was causing the default to be i686 on x86_64 hosts. Either way, the first time this was auto filled in, it's there in the xml to stay, so it won't be easy/impossible to determine what the correct arch value _should_ be if one is already present.
I'm not 100% sure, but that's my guess how it played out. We explicitly set the arch in virtinst now, so with new guests this shouldn't be an issue.