This isn't what Dor suggested in that thread. CCing him

AIUI he said a reasonable default would be to pick some baseline CPU (possibly 2 baseline CPUs, one Intel one AMD) that would give some performance improvements  over the default qemu64-whatever model, and at the same time be nothing too new + fancy so it's very likely our users all have HW that matches the feature flags. This way we get a performance boost, but in the majority of cases users can still migrate guests between their non-uniform hardware.

I'm not saying that's what needs to be done, just that's what Dor seemed to be recommending. For this case I would need input from KVM guys as to what exactly the default CPU model(s) should be.

But whether we use that idea or -cpu host or something else needs to be decided by virt-devel + PM + marketing + performance guys IMO

The main problem here is that any model we choose which isn't the default qemu model is probably going to cause migration issues for someone. Which means someone will eventually file a BZ my way. Before we make any change this stuff needs to be thoroughly documented:

- What the previous default was, why it was the default, its impact on migration and performance
- What the new default is, why it changed, its impact on migration and performace
- What if a migration that worked with a VM created on 6.1 doesn't work with a VM created on 6.2? What is the error the user will see? Are there solutions for this problem, and if so are they different depending on guest OS? How can they avoid this problem for future migrations?
- What do we support for migration? Machines must be same exact hw? same CPU vendor?

Maybe some/all of this is already available.

When all that info is in place, I have no problem changing the virt-manager default to whatever is decided. It's just that eventually the default change will cause migration issues for someone, and when they file a bug I want to be able to point them at the docs and close the bug (provided its not a _real_ bug :) )

Also, it will probably be a bit more work than just changing the default in virt-manager, we will need to provide some way for users to override the default if migration compatibility (or improved performance) is more important to them. Simplest way would be to allow users to manually choose what CPU model to use by default, more user friendly UI would probably be some prechosen list of CPU options that range from maximum migration compatibility (qemu64) to maximum performance (-cpu host). This doesn't need to be perfect for 6.2 as long as things are documented clearly.

We should optimize for the most common case.
Right now that's a user who wants to run a VM locally in which case they will got sub-par performance from KVM.

If a user want to have migration there's more to do than match the CPU, they have to setup shared luns/clustered file systems, ensure they have consistent network topology, etc, etc. Checking the CPU level as part of that checklist is a very small price to pay for a smaller number of users who'll need it. 
Also the most common scenario for clustered VMs is to have a cluster of identical machines so the chances are selecting Nehalem as the cpu would work in the whole cluster.

I DON'T think we should use -cpu host, the suggested change in 700272 is different from the qemu-kvm "-cpu host" option. 

Answering your specific questions

- What the previous default was, why it was the default, its impact on
migration and performance

Previous default is qemu64 which basically lobotomizes a modern CPU to look like a pentium 4. Bad for performance but means that a virtual machine can migrate from a Core2Due from 2008 to a modern Westmere machine can still get the same poor performance.

- What the new default is, why it changed, its impact on migration and
performace

New default should be the maximum supported by the machine - either based on copying the CPU type or using the #700272 approach.
For migration it means that *IF* the user wants to migrate the VM then they'll need to either make sure the hosts are "compatible" or lower the cpu type.

- What if a migration that worked with a VM created on 6.1 doesn't work with a
VM created on 6.2? What is the error the user will see? Are there solutions for
this problem, and if so are they different depending on guest OS? How can they
avoid this problem for future migrations?

The CPU's won't match. Same kind of errors they'd get if they mismatched other resources.

- What do we support for migration? Machines must be same exact hw? same CPU
vendor?
 
No they'd have to be in the same family and of the same class or higher
eg. An Opteron G2 could migrate to a G3 but not to a G1
eg. An Intel Nehalem could migrate to a Westmere but not a core2Duo

Virt-Manager should 'just work' out of the box as fast as possible with little to no tuning.

(In reply to comment #2)
> We should optimize for the most common case.
> Right now that's a user who wants to run a VM locally in which case they will
> got sub-par performance from KVM.
> 

Not sure if the implication here is that I was implying otherwise, because I wasn't trying to convince one way or the other. I'm just saying all the relevant people need to get together, agree on what our story is, and document the hell out of it.

Personally, I think it's pretty reasonable to tell people that if they want to use migration by default they need to a) have uniform hardware or b) plan ahead of time before installing their guests and set them up accordingly.

> If a user want to have migration there's more to do than match the CPU, they
> have to setup shared luns/clustered file systems, ensure they have consistent
> network topology, etc, etc. Checking the CPU level as part of that checklist is
> a very small price to pay for a smaller number of users who'll need it. 
> Also the most common scenario for clustered VMs is to have a cluster of
> identical machines so the chances are selecting Nehalem as the cpu would work
> in the whole cluster.
> 

There is a difference here though between the rest of migration config and a VMs CPU. You can always move storage and network config around transparently to a VM. But you CANT change the CPU after initial guest creation, correct? There's a big difference between "that won't work, move the disk image to shared storage" and 'that won't work, you will need to recreate the VM with a different CPU'

> I DON'T think we should use -cpu host, the suggested change in 700272 is
> different from the qemu-kvm "-cpu host" option. 
> 
> Answering your specific questions
<snip>

I appreciate the answers, but the motivation wasn't really my own edification. I was saying that's what our documentation would need to adequately cover if we are going to change the default. So things like detailed copies of error messages, etc. Your answers are a start but understandably the end user docs should be much more thorough. I'm pretty sure changing the default will piss off some release-note-ignoring user, so we need docs here for CYA at least.

*** Bug 724866 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> I DON'T think we should use -cpu host, the suggested change in 700272 is
> different from the qemu-kvm "-cpu host" option. 

Agreed.  The 700272 approach should provide the highest performance on the host on which the guest was started as well as allowing libvirt to validate migration targets and fail the migration if the target host has an unsuitable CPU.  We must, of course, also provide a very concrete error message explaining what's wrong if the user attempts to migrate to a less capable CPU and we reject the migration for that reason.

> New default should be the maximum supported by the machine - either based on
> copying the CPU type or using the #700272 approach.
> For migration it means that *IF* the user wants to migrate the VM then they'll
> need to either make sure the hosts are "compatible" or lower the cpu type.

I agree with this logic.  IMO, it's a lot easier to throw an error saying, sorry, we can't migrate your VM to that nasty old box in the corner because it's got an ancient CPU than it is to try to ask users up front whether they want maximum performance or the broadest possible set of migration targets, although I could be convinced that it's possible to do UI presenting the user with that choice in a desirable way.

Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

*** Bug 725084 has been marked as a duplicate of this bug. ***

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Jiri, what's the domain XML to copy the host's capabilities?

The XML element which tells libvirt to use a CPU model as close as possible to
host CPU and which allows libvirt to check the CPU during migration is

    <cpu mode='host-model'/>

Dave Allan has commented that this request is more difficult than he'd initially scoped and has pushed it to 6.5 for consideration.

One thing occurred on my mind when reading this BZ.
How about letting the user decide with a simple radio button?

  Set CPU of the guest to maximize:
   (a) migration compatibility [default]
   (b) raw performance

There would be also help strings describing that for detailed CPU specification, the user can customize the configuration before install and what each of these options do.  (a) would be what virt-manager does till now, (b) would do the same as clicking the 'Copy host CPU specification' in the Processor settings.

Just my $0.02.

https://www.redhat.com/archives/virt-tools-list/2013-April/msg00178.html
The patches have been sent out

The 'host-passthrough' is not an option. libvirt 'taints' the VM when using this mode, so virt-manager is not going to place it on UI.

After a discussion in upstream
https://www.redhat.com/archives/virt-tools-list/2013-April/msg00207.html

the 'host-model' is not mature enough to be used in UI currently. The reverting patch has been sent out to revert the above patches.

So keep original, re-evaluate the possibility of change later.
Thanks for Cole, Martin and Jiri's suggestion.

(In reply to Gunannan Ren from comment #23)
> The 'host-passthrough' is not an option. libvirt 'taints' the VM when using
> this mode, so virt-manager is not going to place it on UI.
> 
> After a discussion in upstream
> https://www.redhat.com/archives/virt-tools-list/2013-April/msg00207.html
> 
> the 'host-model' is not mature enough to be used in UI currently. The
> reverting patch has been sent out to revert the above patches.
> 
> So keep original, re-evaluate the possibility of change later.
> Thanks for Cole, Martin and Jiri's suggestion.

Given that, I think that we should not change this behavior in RHEL6, but I agree that this is a useful RFE and should be continued upstream and in future RHEL versions.