Re: [Qemu-devel] QEMU/KVM migration backwards compatibility broken?

[Roman Kagan <rkagan@virtuozzo.com>]

On Thu, Jun 06, 2019 at 01:09:56PM +0300, Liran Alon wrote:
> First, machine-type express the set of vHW behaviour and properties that is exposed to guest.
> Therefore, machine-type shouldn’t change for a given guest lifetime (including Live-Migrations).
> Otherwise, guest will experience different vHW behaviour and properties before/after Live-Migration.
> So I think machine-type is not relevant for this discussion. We should focus on flags which specify
> migration behaviour (such as “x-migrate-smi-count” which can also be controlled by machine-type but not only).

My experience in dealing with migration compatibility matters (see e.g.
9b4cf107b09d18ac30f46fd1c4de8585ccba030c) is that the strategy is
basically "don't let anything but QEMU control what the guest sees".  If
QEMU is started with a particular set of flags defining guest-visible
things (and machine-type is just a convenient preset of flags), and
anything in the environment (host kernel, libraries, etc.) prevents it
from actually providing that functionality, it should detect it before
running any guest code or taking the incoming migration stream, and
refuse to start instead.

AFAICS from a quick glance, QEMU doesn't have a flag to which the
visiblity of MSR_SMI_COUNT is tied, which IMHO is a bug.  As the
presence of this MSR in the CPU is only determined by the CPU model,
it'd probably be correct to just refuse starting when such a CPU is
requested and the host KVM doesn't support MSR_SMI_COUNT.

> Third, let’s assume all hosts in fleet was upgraded to new_kernel. How
> do I modify all launched QEMUs on these new hosts to now have
> “x-migrate-smi-count” set to true?

In (my) ideal world this flag shouldn't have existed.  Dunno how it came
about; I guess it was some sort of a compromise.  The real problem is
IMO that QEMU lets the control loose on whether MSR_SMI_COUNT is present
in the guest.

Roman.