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
On 23 Oct 2020, at 7:02 am, Adam Armstrong via observium <observium@observium.org mailto:observium@observium.org> wrote:
Can this possibly explain a clock going backwards by 20 minutes?
oO
Adam.
Sent from BlueMail http://www.bluemail.me/r?b=16117