The description is horribly confusing. The migration will work or be blocked (or stuck in scheduling) as long as the VM is not using CPU passthrough. That means either the VM.spec.cpu.model has to be set or the default cpu model has to be set in the configmap (like here https://github.com/kubevirt/kubevirt/pull/2028)

Just to make sure we do not simplify that - the machines can have the same CPU physically, but even a microcode update can in theory change one or two flags and prevent migration of VMs with cpu passthrough (host-model).

Martin, 

Have you had a chance to look at Pan's preview build?

Thanks.

devel_acking per Audrey's request.

So, the description is almost right. I would add those notes:

1) the default settings is triggering host CPU passthrough behavior, which can be slightly faster wrt performance, but hinders migration as described
2) the ConfigMap change needs to happen before starting the VMs that are supposed to support live migration
3) an example of cpu model name or a way to figure out the proper name (oc describe node X and look at the cpu-family-NAME labels).

It has been verified few days ago, PR merged: https://github.com/openshift/openshift-docs/pull/16756

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days