Bug 611584 - Won't recognise 64bit cpu on host machine.
Won't recognise 64bit cpu on host machine.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: python-virtinst (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
: Reopened
: 614568 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-05 15:19 EDT by Frank Murphy
Modified: 2013-01-09 06:36 EST (History)
21 users (show)

See Also:
Fixed In Version: python-virtinst-0.500.3-4.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-30 04:33:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
boot screencap (90 bytes, text/plain)
2010-07-05 15:21 EDT, Frank Murphy
no flags Details
/etc/libvirt/qemu/ (90 bytes, text/plain)
2010-07-05 15:23 EDT, Frank Murphy
no flags Details
log from /var/log/libvirt/qemu/ (90 bytes, text/plain)
2010-07-05 15:26 EDT, Frank Murphy
no flags Details
Virsh Capabilities (5.76 KB, text/plain)
2010-07-11 17:50 EDT, Frank Murphy
no flags Details
cat /proc/cpuinfo (741 bytes, text/plain)
2010-07-12 02:43 EDT, Frank Murphy
no flags Details
Virt-Manager --debug (11.43 KB, text/plain)
2010-07-14 18:48 EDT, Frank Murphy
no flags Details

  None (edit)
Description Frank Murphy 2010-07-05 15:19:49 EDT
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:
Comment 1 Frank Murphy 2010-07-05 15:21:43 EDT
Created attachment 429590 [details]
boot screencap
Comment 2 Frank Murphy 2010-07-05 15:23:52 EDT
Created attachment 429591 [details]
/etc/libvirt/qemu/
Comment 3 Frank Murphy 2010-07-05 15:26:20 EDT
Created attachment 429592 [details]
log from /var/log/libvirt/qemu/
Comment 4 Frank Murphy 2010-07-09 03:52:55 EDT
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
Comment 5 Avi Kivity 2010-07-11 12:04:38 EDT
Apparently you selected the pentium3 cpu in virt-manager, which doesn't support 64-bit.

Select something else.
Comment 6 Frank Murphy 2010-07-11 12:28:04 EDT
(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.
Comment 7 Avi Kivity 2010-07-11 12:50:28 EDT
Cole/Daniel?  How did that 'pentium3' get in there?
Comment 8 Richard W.M. Jones 2010-07-11 16:40:19 EDT
Reopening and setting component to virt-manager.

Please run the following command and attach the output to this bug:

virsh capabilities
Comment 9 Frank Murphy 2010-07-11 17:50:06 EDT
Created attachment 431027 [details]
Virsh Capabilities

It seems to be getting the P3 from the host?
Comment 10 Richard W.M. Jones 2010-07-11 18:14:54 EDT
    <cpu>
      <arch>x86_64</arch>
      <model>pentium3</model>

I don't remember the P3 being 64 bit :-(

Libvirt bug perhaps?
Comment 11 Frank Murphy 2010-07-12 02:43:22 EDT
Created attachment 431082 [details]
cat /proc/cpuinfo

This is for one core, otherwise it's 4 of the same.
Comment 12 Frank Murphy 2010-07-12 03:58:59 EDT
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.
Comment 13 Cole Robinson 2010-07-12 10:32:18 EDT
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.
Comment 14 Jiri Denemark 2010-07-12 10:50:08 EDT
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.
Comment 15 Avi Kivity 2010-07-12 11:52:20 EDT
s/lahf_lm/lm/

(lahf_lm indicates the validity of the LAHF instruction in long mode)
Comment 16 Cole Robinson 2010-07-14 15:14:52 EDT
*** Bug 614568 has been marked as a duplicate of this bug. ***
Comment 17 Steve Dickson 2010-07-14 15:23:00 EDT
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'
Comment 18 Fedora Update System 2010-07-14 16:34:38 EDT
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
Comment 19 Cole Robinson 2010-07-14 16:36:36 EDT
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.
Comment 20 Frank Murphy 2010-07-14 18:48:10 EDT
Created attachment 431944 [details]
Virt-Manager --debug

python-virtinst-0.500.3-3.fc13.noarch

No go on an F12 LiveCD
Comment 21 Steve Dickson 2010-07-15 10:57:39 EDT
Its a no go for me either... I'm installing from a DVD
Comment 22 Frank Murphy 2010-07-15 11:16:37 EDT
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.
Comment 23 Cole Robinson 2010-07-15 11:45:53 EDT
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.
Comment 24 Daniel Berrange 2010-07-15 11:54:51 EDT
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.
Comment 25 Frank Murphy 2010-07-15 12:30:32 EDT
(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.
Comment 26 Fedora Update System 2010-07-15 13:30:45 EDT
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
Comment 27 Steve Dickson 2010-07-15 13:44:30 EDT
No go for me.... I'm installing from a DVD
Comment 28 Cole Robinson 2010-07-15 13:55:41 EDT
Steve, please provide --debug output of a failed run. You will need to restart the install, an existing guest won't be automagically fixed.
Comment 29 Frank Murphy 2010-07-15 14:14:33 EDT
(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?
Comment 30 Steve Dickson 2010-07-15 16:20:33 EDT
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...
Comment 31 Fedora Update System 2010-07-15 17:06:48 EDT
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
Comment 32 Fedora Update System 2010-07-30 04:33:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.