Description of problem: Detects cpu incorrectly Version-Release number of selected component (if applicable): qemu 0.12.3.8.fc13.x86_64 How reproducible: always, tested on F12.x86_64.iso&cd F13.x86_64.iso&cd Steps to Reproduce: 1.Open virt-manager add 2. click add vm new icon 3. try to load from x86_64 liveCD or iso Actual results: Cannot detect host has a core2 quad (64bit) http://lists.fedoraproject.org/pipermail/virt/attachments/20100630/d7e61546/attachment.png log from /var/log/libvirt/qemu/ > and the xml from /etc/libvirt/qemu/ ? Expected results: Boot up of iso Additional info:
Created attachment 429590 [details] boot screencap
Created attachment 429591 [details] /etc/libvirt/qemu/
Created attachment 429592 [details] log from /var/log/libvirt/qemu/
If KVM is picked I get the error, If qemu is picked it boots. http://www.zimagez.com/zimage/screenshot-090710-084826.php qemu-kvm-0.12.3-8.fc13.x86_64 qemu-system-m68k-0.12.3-8.fc13.x86_64 qemu-img-0.12.3-8.fc13.x86_64 qemu-user-0.12.3-8.fc13.x86_64 qemu-system-mips-0.12.3-8.fc13.x86_64 qemu-0.12.3-8.fc13.x86_64 qemu-system-arm-0.12.3-8.fc13.x86_64 qemu-system-ppc-0.12.3-8.fc13.x86_64 qemu-system-sh4-0.12.3-8.fc13.x86_64 qemu-system-sparc-0.12.3-8.fc13.x86_64 qemu-common-0.12.3-8.fc13.x86_64 qemu-system-x86-0.12.3-8.fc13.x86_64 qemu-system-cris-0.12.3-8.fc13.x86_64 gpxe-roms-qemu-1.0.0-1.fc13.noarch libvirt-0.8.0-1.fc13.x86_64
Apparently you selected the pentium3 cpu in virt-manager, which doesn't support 64-bit. Select something else.
(In reply to comment #5) > Apparently you selected the pentium3 cpu in virt-manager, which doesn't support > 64-bit. > > Select something else. I don't seem to have such a choice, at least not in the Virt-Manager gui. Even after clicking configure before install.
Cole/Daniel? How did that 'pentium3' get in there?
Reopening and setting component to virt-manager. Please run the following command and attach the output to this bug: virsh capabilities
Created attachment 431027 [details] Virsh Capabilities It seems to be getting the P3 from the host?
<cpu> <arch>x86_64</arch> <model>pentium3</model> I don't remember the P3 being 64 bit :-( Libvirt bug perhaps?
Created attachment 431082 [details] cat /proc/cpuinfo This is for one core, otherwise it's 4 of the same.
Installed a mockbuild of : libvirt-0.8.2-1.fc14 http://koji.fedoraproject.org/koji/buildinfo?buildID=181683 same result. Is there any hack to change from P3? tried editing: /etc/libvirt/qemu/Fedora.Minus.64.xml to show pentium5, no joy.
Jiri pinged me about this on Friday. The problem is that virt-manager (virtinst actually) is unconditionally adding <cpu><model>$HOSTMODEL</model></cpu> to the guest config, where $HOSTMODEL is the host CPU model exposed via virsh capabilities. We did this only in F13/rawhide to facilitate x2apic The issue is that the host CPU model isn't exhaustive: libvirt basically exposes the CPU model that fits the most host features, and then lists each feature the host supports to be thorough. In this case it's Pentium3 + lahf_lm (the 64 bit flag AIUI) and probably others. Possible solutions: 1) By default, make sure to pass lahf_lm to the guest if its present on the host. 2) By default, copy all flags from the host through to the guest. I'm thinking do #1 for F13 since it's the least invasive.
I just realized there's another option: 3) By default, set cpu match attribute to 'minimum' instead of 'exact'. That way the guest would get all features the host supports without the need to copy them to guest XML. On the other hand, when such XML is transferred to a 32b host, the guest would just fail to boot. If the lahf_lm feature is mentioned explicitly, libvirt won't even try to start it complaining about incompatible CPU. So #1 still seems the right a least invasive choice for F13.
s/lahf_lm/lm/ (lahf_lm indicates the validity of the LAHF instruction in long mode)
*** Bug 614568 has been marked as a duplicate of this bug. ***
Note, with in my cause the following errors were in /var/log/message... libvirtd: 14:25:11.616: error : qemudDomainGetVcpus:4795 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain libvirtd: 14:25:11.624: error : qemudDomainGetVcpus:4795 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain libvirtd: 14:25:11.627: error : qemudDomainGetVcpus:4795 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain libvirtd: 14:25:11.630: error : qemudDomainGetVcpus:4795 : Requested operation is not valid: cannot list vcpu pinning for an inactive domain libvirtd: 14:25:23.051: error : qemudDomainLookupByName:3452 : Domain not found: no domain with matching name 'rhel6'
python-virtinst-0.500.3-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/python-virtinst-0.500.3-3.fc13
If one of the reporters could pull down that update package and retry the guest install, I'd appreciate it. If you are still seeing failures, please provide the --debug output of either virt-manager or virt-install (whichever is being used). This won't fix an existing guest that was created incorrectly by the broken package, you will need to delete the guest and kick off a new install.
Created attachment 431944 [details] Virt-Manager --debug python-virtinst-0.500.3-3.fc13.noarch No go on an F12 LiveCD
Its a no go for me either... I'm installing from a DVD
I also added all the flags that virsh capabilities found for the host, to /etc/libvirt/qemu/~64.img int the form: <feature policy="force" name="x2apic"/> (changed it to ro, to prevent overwrite) It still didn't boot. In case any help. <feature name='lahf_lm'/> <feature name='lm'/> <feature name='syscall'/> <feature name='xtpr'/> <feature name='cx16'/> <feature name='ssse3'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> <feature name='ds_cpl'/> <feature name='monitor'/> <feature name='pni'/> <feature name='pbe'/> <feature name='tm'/> <feature name='ht'/> <feature name='ss'/> <feature name='sse2'/> <feature name='acpi'/> <feature name='ds'/> <feature name='clflush'/> <feature name='apic'/> I then downgrade python-virtinst & virt-manager, to the most recent F12, and installed F12.x86_64 LiveCD both booted and Installed.
crap. I should have just done a scratch build and had someone taste, rather than waste an update. I tried another fix of always setting model as either qemu64 or qemu32, but it was choking on my machine, so it sounds like the safest thing to do is just remove this block of code. Unfortunately this will mean guests once again default to qemu32/64 CPUs with no x2apic. I don't really feel comfortable messing with this code anymore unless we make it all configurable. Even trying to add the necc. 64 bit flags is going to give us some unnatural CPU flag combination, so who knows how guests would act. Steps to a proper solution: 1) Add proper UI support for CPU model config, so users can at least opt out if virt-manager screws up (this has always been the goal upstream, just not available yet, and may never end up in F13). 2) Add x2apic to the CPU model definitions in either qemu or libvirt (like was done in RHEL6), so all new guests get the benefit without needing to specify it explicitly 3) Patch libvirt to allow setting CPU flags w/o needing to specify a CPU model. Not sure if this is even an option, but something to consider. Here's a scratch build that is hopefully fixed: http://koji.fedoraproject.org/koji/getfile?taskID=2322113&name=python-virtinst-0.500.3-4.fc13.noarch.rpm Can one of the reporters give it a spin, and provide --debug output if it fails? Thanks.
There are a few sensible default options * omit CPU entirely. * Copy the full host CPU model + flags * Perform a CPU baseline across a set of hosts & use the result * Pick a random CPU model + flags & check it is compatible with host using virConnectCompareCPU Picking qemu64 + x2apic should have been safe, if you made sure to use virConnectCompareCPU for validation first.
(In reply to comment #23) > > Here's a scratch build that is hopefully fixed: > http://koji.fedoraproject.org/koji/getfile?taskID=2322113&name=python-virtinst-0.500.3-4.fc13.noarch.rpm > > Can one of the reporters give it a spin, and provide --debug output if it > fails? Thanks. +1 Booted F13_64 live.iso Installed it. Successfully rebooted installed img, more than once. All I have is a thank you.
python-virtinst-0.500.3-4.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/python-virtinst-0.500.3-4.fc13
No go for me.... I'm installing from a DVD
Steve, please provide --debug output of a failed run. You will need to restart the install, an existing guest won't be automagically fixed.
(In reply to comment #27) > No go for me.... I'm installing from a DVD I've just burned a fresh F13_64 DVD, boots fine. If any benefit can do an install?
I stand corrected... I guess I either and to restart virt-manager and/or reboot because when I did both I was able to boot...
python-virtinst-0.500.3-4.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update python-virtinst'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/python-virtinst-0.500.3-4.fc13
python-virtinst-0.500.3-4.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.