Re: [PVE-User] Old, 32bit, debian and clock drift.

[Marco Gaiarin <gaio@lilliput.linux.it>]

Mandi! Arjen via pve-user
  In chel di` si favelave...

> Sorry, I must have missed that. Other people also encountered your problem:
>  https://v13.gr/2016/02/15/running-an-ntp-server-in-a-vm-using-kvm/
> Instead of disabling ntpd, do not use the kvm-clock source on the NTP server VM.
> Either way, make sure not to combine the two.

OK, i've give it a try, for now, manually changing the clocksource with:

	echo 'hpet' > /sys/devices/system/clocksource/clocksource0/current_clocksource

But some things seems strange to me...

1) this happen on *TWO* VMs in two different installation; i've dozen of
similar installation where:

	root@vdmsv1:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
	kvm-clock

and clock are perfectly in sync; true that these problematic VMs are pretty old debian,
but not older than others that works as expected.


2) other docs, like:
	https://docs.oracle.com/en/database/oracle/oracle-database/21/ladbi/setting-clock-source-vm.html

confirm that 'tsc' is the preferred clock source for VMs; but in these box
that depicted the trouble, 'TSC' clock source get 'kicked off' because
'unreilable'.


So, doing a little 'survey' on my VMs, seems that *all* VMs use by default
'kvm-clock' as the default clock source, but on those two VMs 'tsc' clock
source is unreilable, and get kicked off, and 'kvm-clock' is unreilable too,
but get not kicked off.


Really, really strange...

-- 
  Chi parla male, pensa male e vive male.
  Bisogna trovare le parole giuste: le parole sono importanti!
						Nanni Moretti in Palombella Rossa