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.
