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: | libvirt | Assignee: | Daniel Veillard <veillard> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | berrange, clalance, crobinso, hbrock, itamar, markmc, quintela, veillard, virt-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-04-06 13:13:45 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Jasper Capel
2009-04-06 08:20:33 UTC
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:
<os>
<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. |