Bug 611584

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.