Bug 494286

Summary: Unable to boot because libvirt uses '-cpu qemu32' with x86_64 virtual machine
Product: [Fedora] Fedora Reporter: Jasper Capel <fedora-jasper>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: berrange, clalance, crobinso, hbrock, itamar, markmc, quintela, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-06 09:13:45 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Erroneous domain XML file none

Description Jasper Capel 2009-04-06 04:20:33 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):

How reproducible:
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.

Actual results:
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".

Expected results:
Virtual Machine boots.

Additional info:
/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 -k en-us

qemu-kvm -cpu ? gives me the following output:
x86           qemu64
x86           phenom
x86         core2duo
x86           qemu32
x86          coreduo
x86              486
x86          pentium
x86         pentium2
x86         pentium3
x86           athlon
x86             n270

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. :)
Comment 1 Jasper Capel 2009-04-06 04:48:40 EDT
This error does not occur when I install a new machine (in this case using cobbler+koan).
Comment 2 Mark McLoughlin 2009-04-06 04:58:21 EDT
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>
Comment 3 Jasper Capel 2009-04-06 05:16:17 EDT
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.
Comment 4 Mark McLoughlin 2009-04-06 05:37:52 EDT
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?
Comment 5 Daniel Berrange 2009-04-06 05:41:57 EDT
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.
Comment 6 Jasper Capel 2009-04-06 05:44:17 EDT
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.
Comment 7 Jasper Capel 2009-04-06 06:16:42 EDT
Changing the arch to x86_64 using virsh edit worked, thanks.
Comment 8 Mark McLoughlin 2009-04-06 09:13:45 EDT
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.
Comment 9 Cole Robinson 2009-04-06 11:58:55 EDT
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.