On Wed, Jun 28, 2017 at 04:24:39PM +0200, Jiri Denemark wrote: > When checking ABI stability between two domain definitions, we first > make migratable copies of them. However, we also asked for the guest CPU > to be updated, even though the updated CPU is supposed to be already > included in the original definitions. Moreover, if we do this on the > destination host during migration, we're potentially updating the > definition with according to an incompatible host CPU. > > While updating the CPU when checking ABI stability doesn't make any > sense, it actually just worked because updating the CPU doesn't do > anything for custom CPUs (only host-model CPUs are affected) and we > updated both definitions in the same way. > > Less then a year ago commit v2.3.0-rc1~42 stopped updating the CPU in > the definition we got internally and only the user supplied definition > was updated. However, the same commit started updating host-model CPUs > to custom CPUs which are not affected by the request to update the CPU. > So it still seemed to work right, unless a user upgraded libvirt 2.2.0 > to a newer version while there were some domains with host-model CPUs > running on the host. Such domains couldn't be migrated with a user > supplied XML since libvirt would complain: > > Target CPU mode custom does not match source host-model > > The fix is pretty straightforward, we just need to stop updating the CPU > when checking ABI stability. > > https://bugzilla.redhat.com/show_bug.cgi?id=1463957 > > Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> > --- > src/qemu/qemu_domain.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx>
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
