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 ``` # 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
signature.asc
Description: PGP signature
