Op maandag 23 juni 2014 15:54:13 UTC+2 schreef David Woolley:
On 23/06/14 13:12, Miroslav Lichvar wrote:
I think it all depends on the VM implementation and what clocksource
is used in the guest. If the guest is using tsc (i.e. its frequency is
independent of the host clock), it will need to run its own NTP
It will still be subject to potentially large scheduling delays between
NTP packet arrival and processing. Also, unless you restrict VM to a
single host, the TSC could jump and change frequency when the VM is
moved. If it is impossible to virtualise TSC, it is impossible to hide
those jumps.
Not sure what it's worth and how it is implemented on other virtualisation
platforms but according to vmware docs they have a virtual tsc. It is set when
the vm is powered on but when the vm is moved to a different host (or resumed
more generally) it keeps its original power-on tsc rate.
In practice, on vmware, I see that the system clock jumps a few hundred of ms
after a move to another host. Maybe because of delays in the process of setting
the system clock to the clock of the new vmware host on resume.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions