Description of problem:

First: I am splitting bug-report 700553 into several specific issues.

When creating a new guest, you MUST make SURE to change cpu settings, and 
set "copy_cpu_host" otherwise you end up creating an underpowered cpu which
is like a 386 more or less, and it even tends to crash the guest and consume
all the host cpu as if that where enough. 

The default virt-manager options produces an underpowered cpu for the guest,
in a wxp guest, cpu-z reports it as a k6 with mmx and barely any other flags,
using "copy_cpu_host" and apply produces a normal guest which cpu-z reports 
as a phenom quad-core (it is closer to the real cpu).

A centos 5.3 host (previously created, cirrus, ide:raw):

The default cpu offered to the guest was:

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model  : 2
model name : QEMU Virtual CPU version 0.14.0
stepping : 3
cpu MHz  : 2600.054
cache size : 512 KB
fpu  : yes
fpu_exception : yes
cpuid level : 4
wp  : yes
flags  : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
clflush mmx fxsr sse sse2 syscall nx lm up pni cx16 popcnt lahf_lm altmovcr8
abm
bogomips : 5267.46
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

And after using "copy_host_cpu" (it set it to opteron_g3)

processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model  : 2
model name : AMD Phenom(tm) 9550 Quad-Core Processor
stepping : 3
cpu MHz  : 2600.060
cache size : 512 KB
fpu  : yes
fpu_exception : yes
cpuid level : 5
wp  : yes
flags  : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb lm up pni
cx16 popcnt lahf_lm cmp_legacy svm cr8_legacy altmovcr8 abm sse4a misalignsse
bogomips : 5419.09
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

Now, with the FX6100, i get (opteron_g3) but the guest sees it as a Core2 Duo
T7700. So AMD cpus are now INTEL... very funny. The vendor_id is AuthenticAMD and the cpu family is 6. A true chimera. 

The issue is that is just to EASY to make an unusable guest.
The gui called 'virt-manager' needs a bit of an overhaul. 
Maybe for F17 or F18, but it cannot continue like that.


Selecting copy_host_cpu solves the problem but creates another small issue:
* i recently upgraded motherboard+cpu (form nvidia+phenom2x3 to amd+fx6100)
  and i needed to reapply 'copy_host_cpu'. 
  Should copy_host_cpu mean "copy the HOST cpu" and not copy the host cpu in x
  moment and use x everytime?


For example, after the mb+cpu upgrade, some guest inform:

Error starting domain: internal error guest CPU is not compatible with host CPU

Traceback (most recent call last):º
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/engine.py", line 959, in asyncfunc
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 1128, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 330, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error guest CPU is not compatible with host CPU

which is fixed by resync of what the host cpu is, but i already tell it
to copy it, or maybe whe need a new option, "always use the host cpu".


Version-Release number of selected component (if applicable):

Running Fedora 15, have 16 installed in another staging partition to test if necesary.

libvirt.x86_64              0.8.8-7.fc15           @updates
libvirt-client.x86_64       0.8.8-7.fc15           @updates
libvirt-python.x86_64       0.8.8-7.fc15           @updates
virt-manager.noarch         0.8.7-6.fc15           @updates
virt-viewer.x86_64          0.3.1-1.fc15           @fedora

How reproducible:
allways.

Steps to Reproduce:
1. create a guest without customizing the guest before install.
2. slow cpu is created
  
Actual results:
the guest cpu is very slow and / or incorrect expected type. Os may even crash, depening of wich one. Linux guests tend to crash.

Expected results:
no guest crashes nor slowdowns, as long as there is ram an host cpu left.
do not consume host cpu with one small guest that tends to crash.

Additional info:
Tested allways on AMD cpus.

Phenom II X3 on M4N72-E          (nvidia)  8GB RAM user since 2009
Phenom II X3 on SABERTOOTH 990FX (amd)    16GB RAM motherboard upgrade
FX 6100      on SABERTOOTH 990FX (amd)    16GB RAM cpu ugrade

virt-manager experience got broken around the last month before 13 was EOLed.
A PhenomII X3 with 8gb of ram was not suitable for virtualization after that.
I never used F14. With F13, i was able to downgrade to some version and continued using it. Then installed F15 and here i am.