"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * Antoine Damhet (antoine.dam...@blade-group.com) wrote: >> On Thu, Sep 17, 2020 at 06:44:10PM +0100, Dr. David Alan Gilbert wrote: >> >> [...] >> >> > > >> > >> > > >> > Shouldn't the old check used when machine type <= 5.1 in order to >> > > >> > avoid >> > > >> > migration incompatibility ? >> > > >> >> > > >> Hm, when the check fails we just don't create the device and no error >> > > >> is >> > > >> reported, so even if we have kvmclock data in the migration stream but >> > > >> fail to create it migration will still succeed, right? (not a >> > > >> migration >> > > >> expert here :-) >> > > > >> > > > When the migration stream is parsed, it'll try and find a "kvmclock" >> > > > device to pass the data it's reading to; if one doesn't exist it'll >> > > > fail. >> > > >> > > This may happen with an older machine type when the destination is >> > > running an unfixed QEMU and the source has the fix, right? >> > >> > Yes I think so. >> > >> > > The solution >> > > would be to introduce a flag for older machine types (or for new ones) >> > > like 'kvmclock_always'. >> > >> > Yep sounds the normal answer. >> > (You might want to try it first to trigger the bug) >> >> So, I tried the patch and: >> >> # patched -> patched >> >> Everything working as expected >> >> # patched -> unpatched >> >> Migration failure with: >> >> ``` >> Unknown savevm section or instance 'kvmclock' 0. Make sure that your current >> VM setup matches your saved VM setup, including any hotplugged devices >> load of migration failed: Invalid argument >> ``` > > Right, that's what I expected and said we need to wire this fix to the > machine type. >
v2 with the idea implemented is coming. As I'm not a regular contributor to machine types, please review thoroughly :-) -- Vitaly
