That only explains why a VM clock could
be 'behind' normal time. Not really how it was a xx *inside the
vm* and suddenly it's at xx-30.
The sudden timesync could after
vmotion, but no sane person would ever sync time from hypervisor
to VM.
Tom
On 2020-10-22 22:26, Michael via
observium wrote:
Yes, it can. If the hypervisor clock is that far out of sync.
During boot and also during the vmotion process, the
guest does the equivalent of an 'ntpdate' which forcefully syncs
the time, regardless of how far offset it is against the local
clock (local being the pseudo-clock within the vm).
The concept, at least with vmotion, is to provide a
correction for the "stunning" that the VM receives during the
process (think of it as being punched in the face). The guest
gets momentarily stunned to halt so that memory and CPU state
can be copied out from underneath it. It does this repeatedly
until all of the state can be transitioned. Obviously, depending
on how large/busy the VM is, this could cause the original VM to
drift a bit from reality.
M
Can this possibly explain a clock
going backwards by 20 minutes?
oO
Adam.