* 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. Dave > > # unpatched -> patched > > The guest hangs upon arrival, I don't know which value is restored but > something is restored (and far enough from 0 to confuse Windows). > > > > > > > The other question is in the incoming direction from an older VM; > > > > you'll have a kvm clock created here, but you won't load the kvm clock > > > > state from the migration stream - what is this clock going to do? > > > > > > This is not really a problem I believe: the clock was absent on the > > > source and things somehow worked for the guest so even if we don't > > > initialize kvmclock properly on the destination nothing bad is expected. > > > > OK. > > > > Dave > > [...] > > -- > Antoine 'xdbob' Damhet -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
