vmware ntp probleem

[koos147]

heb al aardig wat lopen google en eeen hoop niet werkende oplossingen gevonden

ik heb een debian server met vmware server
als virtuele machine heb ik zowel windows als linux machines

op de windows machines blijft de klok goed lopen
op de linux machines loopt de tijd langzamer als de huidige tijd
ik heb dit geprobeert op te lossen met een ntp client
dit werkt echter niet de klok blijft gewoon achter lopen

als ik met ntpdate de klok handmatig goed zet loopt het soms in de duizende secondes

ik ben bang dat de ntp client zoiets heeft van het verschil tussen de klok en de informatie die ik binnen krijg is te groot dus dat ga ik niet uitvoeren

als dit zo is weet iemand dan de oplossing om dit te overrullen?

Met vriendelijke groet
Mark

[Mark309]

Hoi Mark,

Het probleem zit hem waarschijnlijk niet in je NTP Client maar in de manier waarop de virtual machine tegen de hardware klok aankijkt. In je windows VMs lossen de vmware tools dit probleem op, hoe dit met de linux VMs zit weet ik niet .

Wat ik wel weet is dat vmware er een heel document over volgeschreven heeft: vmware timekeeping pdf

Daarin staat onder andere:

Timekeeping in Linux has changed a great deal over its history. Recently, the direction of kernel development
has been toward better behavior in a virtual machine. However, along the way, a number of kernels have had
specific bugs that are strongly exposed when run in a virtual machine. Some kernels have very high interrupt
rates, resulting in poor timekeeping performance and imposing excessive host load even when the virtual
machine is idle. In most cases, the latest VMware‐supported version of a Linux distribution has the best
timekeeping behavior

Misschien heb je er iets aan

[leuk_he]

inderdaad, vmtools in guest installeren zou een oplossing zijn.

[koos147]

dat was ik vergeten te melden

voor vmware tools heb je een grafiche interface nodig

de installatie gaat prima zonder maar vervolgens kun je er niets aan instellen

[Saturnus]

Voordat je de OS start kan je in de 2e tab van "Configure VM" aangeven of je wilt laten synchen met de host.

Nu heb ik op dit moment ook problemen met de tijd: De host loopt steeds (moet nog een oorzaak zoeken) bijna 10 min. achter...sync stond aan dus de VM's stonden ook verkeerd...

[loser180]

Command line is voldoende voor vmtools

[leuk_he]

hmm, ik moet hierop terugkomen...

vmware recommandations:
http://www.vmware.com/files/pdf/linux_install_config.pdf

Whenever possible, use NTP instead of VMware Tools periodic time synchronization.

Staat ook een configuratie...

NOTE The directive tinker panic 0 must be at the top of the ntp.conf file.

Wat de zorgen van de topic starter over te grote tijdverschillen oplost.

[ Voor 25% gewijzigd door leuk_he op 21-07-2009 16:43 ]

[koos147]

ik heb mijn ntp.conf aangepast
vanwege winbind moeten de servers gelijk lopen met de windows servers

code:

tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 172.16.1.1
server 172.17.1.2
server 172.16.10.1
driftfile /var/lib/ntp/drift

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fnet-dc3.fneton 194.171.167.130  2 u   62   64  377    1.621  73742.2 23273.4
 fnet-dc5.fneton 172.16.10.1      3 u   63   64  377   30.308  97780.3 39554.2
 172.16.10.1     194.171.167.130  2 u   59   64  377    2.513  41903.1 34983.5

na een 10 minuten kom ik dan met ntpq -p op bovenstaand resultaat
het aparte is echter dat alle servers exact dezelfde tijd hebben (ik heb de bovenste en de onderste gecontroleerd die lopen helemaal gelijk )
toch zit er een heel groot verschil in de offset


/edit
een uurtje later ziet het er als volgt uit

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fnet-dc3.fneton 194.171.167.130  2 u   64   64  377    1.058  596946. 32913.4
 fnet-dc5.fneton 172.16.10.1      3 u   26   64  377   30.637  598125. 35443.0
 172.16.10.1     194.171.167.130  2 u    1   64  377    0.911  626540. 20221.7

[ Voor 19% gewijzigd door koos147 op 22-07-2009 14:23 ]

[Question Mark]

Ook nog zaken in het bios aanstaan die bij lage load de cpu van de host terugklokken (Cool 'n Quit, Speedstep, etc). Dat wil ook nog wel eens voor dergelijke problemen zorgen.

[koos147]

ik heb de lijst met ntp servers een beetje uitgebreid met externe pool servers (verschillende van ntp.org)
wat mij echter opvalt is dat er tussen de pool servers ook grote verschillen in tijd zitten
is dat normaal of snapt mijn ntp client het niet meer?

code:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 fnet-dc3.fneton 194.171.167.130  2 u   37   64    7    2.666  5150.14 14124.8
 fnet-dc5.fneton 172.16.10.1      3 u   38   64    7   29.370  5114.44 13733.6
 ntp1.hro.nl     192.87.36.4      2 u    3   64   17    9.996  19075.1 12388.2
 dedicated.aimms 193.79.237.14    2 u   50   64    7    6.294  11071.7 9128.62
 mx1.xillhosting 194.171.167.130  2 u    7   64   17    2.683  25283.8 17255.6
 ntp0.bbactive.e 130.149.17.8     2 u   56   64    7    4.091  20682.9 15073.6
 ams1.x31.com    193.67.79.202    2 u   44   64    7    2.852  13011.3 8871.76
 arethusa.tweake 193.79.237.14    2 u   37   64    7    2.743  15271.2 8775.77
 www.lecad.uni-l 193.2.1.92       2 u    5   64   17   25.631  9152.57 11834.7
 85.21.78.91     193.190.230.65   2 u   34   64    7   35.680  15414.9 8600.75
 193.65.58.58    62.119.40.98     2 u   29   64    7   40.348  17161.2 8616.96
 monitoring.graf 193.67.79.202    2 u   17   64   17    1.178  1569.15 19813.2

de bovenste 2 servers staan binnen het netwerk de rest is pool


@?
de bios van de vmware server zelf kan ik niet bereiken omdat hij in het datacenter hangt
volgens mij is dat voor de vmware guest geen optie

[ Voor 4% gewijzigd door koos147 op 24-07-2009 11:03 ]

[Question Mark]

koos147 schreef op vrijdag 24 juli 2009 @ 11:02:

@?
de bios van de vmware server zelf kan ik niet bereiken omdat hij in het datacenter hangt
volgens mij is dat voor de vmware guest geen optie

Je moet het inderdaad in het bios op de host aanpassen. VMWare heeft er zelfs een KB-artikel over:

Host Power Management Causes Problems with Guest Timekeeping on Linux Hosts

This problem occurs because current VMware for Linux products do not have complete support for host power management features (such as Intel SpeedStep, or AMD PowerNow or Cool'n'Quiet) that vary the processor speed. This article gives one workaround that prevents guest clocks from running quickly and another that periodically corrects the time when guest clocks run slowly. Alternatively, for more accurate time, you can lock the host processor to a constant speed; see knowledge base articles 708 and 916 at the links above.

[!null]

koos147 schreef op dinsdag 21 juli 2009 @ 15:50:
als ik met ntpdate de klok handmatig goed zet loopt het soms in de duizende secondes

Wat bedoel je hiermee? Je hebt ook een flag dat je hem forced te synchroniseren, ook al is het verschil over de 1000s (normaal gesproken stopt hij dan).

Verder heb ik wel vaker rare dingen gehoord over tijd in VM's. Verder zien de waardes van je ntpq -p printjes er ook niet al te zonnig uit. Zijn vrij ernstige waardes qua delay/jitter/offset.

Hoe kritisch is de toepassing? Je zou ook een cronjob kunnen doen die dan met ntpdate of ntpd -q de tijd eenmalig zet, iedere minuut. Maar dat is een houtje toutje oplossing natuurlijk, en kom je misschien niet eens mee vooruit.

En wat zegt ntpstat?

[leuk_he]

Nogmaals de vraag:
-Heb je vmtools geinstalleerd? Als je zowel vmtools sync gebruikt en ntp skewed timed dan kan ik me er iets bij voorstellen. kies.
-Heb je een kernel met paravirtulisation (dmesg | grep VMI).
-Enig idee of de vmware server druk is? dan is de kans groot dat je timer ticks mist/moet inhalen.