'-cpu host' is not something that we intend to support in libvirt, because it is an opaque blob whose semantics cannot be determined, queried, analysed. Furthermore it is completely redundant given the capabilities already present in the libvirt CPU description framework.

You can get the equivalent of -cpu host by running 'virsh capabilities' (or the API) to query the current host <cpu> description, and then copying that <cpu> unchanged into the guest XML.  At most we could add a syntactic sugar at the XML input stage where <cpu><model>host</model></cpu> gets automatically expanded into the full <cpu> XML from the capabilities.

If there are aspects like cache size, etc that aren't currently tracked in libvirt, those should be added to the <cpu> description.

(In reply to comment #2)
> '-cpu host' is not something that we intend to support in libvirt, because it
> is an opaque blob whose semantics cannot be determined, queried, analysed.
> Furthermore it is completely redundant given the capabilities already present
> in the libvirt CPU description framework.

Understandably this may not have the most elegant solution
within the existing libvirt framework as the exposed cpu
model is a moving target.

> You can get the equivalent of -cpu host by running 'virsh capabilities' (or the
> API) to query the current host <cpu> description, and then copying that <cpu>
> unchanged into the guest XML.  At most we could add a syntactic sugar at the
> XML input stage where <cpu><model>host</model></cpu> gets automatically
> expanded into the full <cpu> XML from the capabilities.

I believe the bottom line goal here is to deskill the task for the
user to "clone the guest CPU features from the host".  "-cpu host"
continues to be used in this context (perhaps a bit too loose) as
the qemu-kvm myopic means to do so.  Whatever can be done within
libvirt to provide the same functionality effectively solves the
same problem.  While the "-cpu host" mechanism exists today and
would give us one vs. potentially two mechanisms to validate and
support, it obviously isn't the only consideration.
 
> If there are aspects like cache size, etc that aren't currently tracked in
> libvirt, those should be added to the <cpu> description.

That is under consideration and is probably an overall easier issue
to address from libvirt's perspective than it is for qemu.  Currently
qemu doensn't have any general mechanism to deal with cpu features
outside of cpuid.  And not all of (in this case) memory hierarchy
is representable within the cpuid framework.

> I believe the bottom line goal here is to deskill the task for the
> user to "clone the guest CPU features from the host". "-cpu host"
> continues to be used in this context 

This is irrelevant from a libvirt API/XML design POV, since it is describing a end user interface design issue. The mechanism I describe can trivially be automated in 1-click in virt-manager/RHEV-M, or with a single command line arg in virt-install.  Ease of end user editing of XML is a non-requirement in libvirt.

Seems reasonable to me, but let's hear from the UI folks.
Reassigning to virt-manager.

Yeah, the plan for exposing the CPU config in virt-manager is to also have an option like 'Copy host CPU settings' which will setup the libvirt equivalent of -cpu host. virt-install will also have a similar option.

This is mostly upstream now.

virt-install has a -cpu option that is very similar to qemu. Some valid values

--cpu core2duo,+x2apic,-vmx
--cpu host
--cpu qemu32,match=minimum,disable=vmx

virt-manager additionally has a 'Configuration' section in the VM Details->CPU page. This allows selecting a CPU model from a drop down of valid libvirt models, manually entering one, or alternately auto populating the fields with a button 'Copy host CPU configuration':

http://fedorapeople.org/~crobinso/virt-manager/vmm-cpu-host.png

The only thing missing is a way in the UI to manually enable/disable individual features but i'll be doing that shortly.

(despite not showing features/vendor fields, these values _are_ copied. I just didn't think there was much of a reason to allow manually specifying the vendor value, but correct me if I'm wrong)

Note that in RHEL we only support these models:
x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
x86      cpu64-rhel5  QEMU Virtual CPU version (cpu64-rhel5)
x86      cpu64-rhel6  QEMU Virtual CPU version (cpu64-rhel6)

from http://cleo.tlv.redhat.com/qumrawiki/KVM/CPUModels
John, it might be good to hide the others in this wiki

(In reply to comment #7)

> The only thing missing is a way in the UI to manually enable/disable individual
> features but i'll be doing that shortly.
> 
> (despite not showing features/vendor fields, these values _are_ copied. I just
> didn't think there was much of a reason to allow manually specifying the vendor
> value, but correct me if I'm wrong)

In general allowing a user to modify individual cpuid data is
helpful for debug of models without having to wander outside of
libvirt context.  If I follow your comment accurately -- not
exactly sure what you were referring to as "vendor value" above.

(In reply to comment #8)
> Note that in RHEL we only support these models:
> x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
> x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
> x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
> x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
> x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
> x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
> x86      cpu64-rhel5  QEMU Virtual CPU version (cpu64-rhel5)
> x86      cpu64-rhel6  QEMU Virtual CPU version (cpu64-rhel6)
> 
> from http://cleo.tlv.redhat.com/qumrawiki/KVM/CPUModels
> John, it might be good to hide the others in this wiki

I was trying to accurately describe the models known by qemu-kvm-rhel6
and reported to the user.  But I'd agree it probably is best not to
advertise unsupported models.  It takes forever for them to fade away
as it is.  Changed in wiki.

Dor, Cole said in comment 7 that this work was largely done upstream and that what remained would be done shortly.  Does what Cole described in comment 7 not fulfill what you're looking for?

(In reply to comment #12)
> Dor, Cole said in comment 7 that this work was largely done upstream and that
> what remained would be done shortly.  Does what Cole described in comment 7 not
> fulfill what you're looking for?

It looks good enough for me, changing specific cpuid flag is nice to have but less important as the above standard models.

(In reply to comment #12)
> Dor, Cole said in comment 7 that this work was largely done upstream and that
> what remained would be done shortly.  Does what Cole described in comment 7 not
> fulfill what you're looking for?

It looks good enough for me, changing specific cpuid flag is nice to have but less important as the above standard models.

Fixed in virt-manager-0.8.6-1.el6

checked with virt-manager-0.8.6-1.el6

Steps:
1.create a guest 
2.on virt-manager, double click guest, and click the guest detail button . 
3.click the Processor option. 
4.on the right pan , there is the Configuration Frame , we can press the Copy host CPU configuration 

Effect :
1. the exact host processor vendor would be copied into the droplist 
2. virsh dumpxml guest will get 
    <cpu match='exact'>
    <model>Opteron_G3</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='mmxext'/>
    <feature policy='require' name='fxsr_opt'/>
    <feature policy='require' name='cr8legacy'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='3dnowprefetch'/>
    <feature policy='require' name='3dnowext'/>
    <feature policy='require' name='extapic'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='osvw'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='3dnow'/>
  </cpu>
3. start the guest , ps -aef |grep kvm will get 

/usr/libexec/qemu-kvm -S -M rhel6.1.0 -cpu Opteron_G3,+osvw,+3dnowprefetch,+cr8legacy,+extapic,+cmp_legacy,+3dnow,+3dnowext,+pdpe1gb,+fxsr_opt,+mmxext,+ht,+vme -enable-nesting -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name rhel6 -uuid 875b8f57-afa1-561e-dadb-ec8709c828f3 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel6.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/rhel6.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=22 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2f:8f:18,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

The -cpu host is set by virt-manager and could be parsed by qemu-kvm . 

So set bug status to VERIFIED .

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0637.html