[fbsd-7] tijd in vmware guest loopt niet goed

[Boudewijn]

Hoi,

Ik heb een debian amd64 doos met FreeBSD als guest os.
in debian loopt de tijd gewoon prima.

VMware Server 1.0.6 build-91891
calzone 2.6.18-6-amd64 #1 SMP
Default kernel dus, maar wel SMP.

dmesg en het syslogje zeggen niets raars (idd niet vreemd omdat in debian de zaak prima klopt).


In freebsd:

in dmesg:
Timecounters tick every 1.000 msec

Syslogje:

code:

Sep  6 22:00:00 calzone-mail kernel: Uptime: 16m21s
Sep  6 22:00:00 calzone-mail kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Sep  6 22:00:00 calzone-mail kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Sep  6 22:00:00 calzone-mail kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
Sep  6 22:00:00 calzone-mail kernel: Timecounters tick every 1.000 msec
Sep  6 22:34:26 calzone-mail kernel: Uptime: 4m45s
Sep  6 22:34:26 calzone-mail kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Sep  6 22:34:26 calzone-mail kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Sep  6 22:34:26 calzone-mail kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
Sep  6 22:34:26 calzone-mail kernel: Timecounters tick every 1.000 msec
Sep  6 22:51:00 calzone-mail kernel: Uptime: 2m14s
Sep  6 22:51:00 calzone-mail kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Sep  6 22:51:00 calzone-mail kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Sep  6 22:51:00 calzone-mail kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
Sep  6 22:51:00 calzone-mail kernel: Timecounters tick every 1.000 msec

Gewoon een standaard freebsd-7 install, zonder rare kernel oid (gewoon stock model).

ntp-syncen werkt prima, maar de klok loopt vanzelf fout.

code:

tools.syncTime = "TRUE"

Dit aan het vmware VMX bestand toevoegen helpt ook niet.


Weet iemand waar dit aan kan liggen? Het gaat hier om 1-2 uur verschil per dag, ook al sync ik meerdere malen per dag met een ntp-server (die sync gaat goed).

[axis]

Voeg aan je /boot/loader.conf toe:

code:

kern.hz="100"

Werkt in ieder geval prima bij mijn ESX guests, staat ergens in het vmware forum, en sommige vmtools geven dit ook als opmerking, maar ik weet niet meer precies waar ik het vandaan heb.

Dan draait de tijd in ieder geval redelijk ok, en is dit probleem verholpen.

Daarnaast draai ik nog ntpd, die er continu voor zorgt dat je klok goed staat (ntpdate synched eenmalig, en ntpd werkt iets anders, die past niet opeens je tijd aan, maar die zorgt dat je clocktickjes net iets sneller of langzamer lopen).

[ Voor 96% gewijzigd door axis op 14-09-2008 23:45 ]

[Boudewijn]

Dank je wel, dat gaan we eens proberen .

ntpd is ook een optie, maar ik vind het een beetje zonde om het op die manier te 'workarounden' ipv het probleem bij de bron aan te pakken.

[ Voor 62% gewijzigd door Boudewijn op 14-09-2008 23:46 ]

[blaataaps]

"meerdere keren ntpdate per dag" vervangen door ntpd is hoe dan ook een goed idee lijkt me, niet alleen om te workarounden?

[Boudewijn]

True, maar dat was meer om aan te tonen dat het echt enorm hard verloopt.
Hij stond net om 00:05 (na reboot ) op 0:00 ,bij een sync met dezelfde server (xs4all-ntp, die is voor beide machines het dichtste bij).

Zal morgenochtend eens kijken of dat meer is geworden. Om 00:28 lopen we al 13 minuten achter (fbsd denkt dat het 0014 is).

Om 0040 denkt de server in 0020 te leven. Niet goed, met zowel ntpdate als die fix in loader.conf.
Niet echt acceptabel dus .

[ Voor 27% gewijzigd door Boudewijn op 15-09-2008 00:41 ]

[Rainmaker]

ntpd is niet echt een optie; na een keer of 100 corrigeren exit ntpd omdat ie teveel afwijking heeft met de "echte" klok.

Geeft je wel een betrouwbare tijd voor een paar uur, maar langer word lastiger.

[axis]

Hmm vreemd dat die kern.hz optie niet werkt, bij ESX dus wel..

misschien kun je hiermee nog wat meer info vinden..

[Boudewijn]

code:

[boudewijn@calzone-mail ~]$ date
Mon Sep 15 08:50:11 CEST 2008

het is nu 14.17.
Huge afwijking dus, ook met ntpd.

http://taosecurity.blogsp...-freebsd-61-guest-on.html

helpt dus ook niet, helaas.

http://lists.ntp.isc.org/...2005-December/001877.html

Ook nog gelezen, maar dit helpt ook niet.

[ Voor 54% gewijzigd door Boudewijn op 15-09-2008 16:55 ]

[wzzrd]

ESX is berucht om de slechte tijdsynchronisatie tussen host en (*nix) guest. Op de VMware kb zijn een paar artikelen te vinden om dit te verhelpen, maar de gaan grotendeels over Linux.

Als je boven in je ntp.conf zet:

code:

tinker panic 0

draait ntpd gewoon door bij grote afwijkingen e.d.

Stel ook je step-tickers in voor een sync tijdens boot. Zet de synctime optie uit en draai dus ntpd.

Dat raadt VMware tegenwoordig zelf ook aan als 'best practice'.

* wzzrd is benieuwd of hij hier nieuws over gaat horen op VMworld, volgend jaar...

[Boudewijn]

Nou het gaat hier niet om ESX (gewoon vmware server), maar ik ga het iig wel proberen.

[wzzrd]

Boudewijn schreef op dinsdag 16 september 2008 @ 13:10:
Nou het gaat hier niet om ESX (gewoon vmware server), maar ik ga het iig wel proberen.

Ja, ik zie het: daar had ik de eerste keer overheen gelezen

[Boudewijn]

wzzrd schreef op dinsdag 16 september 2008 @ 08:54:
Stel ook je step-tickers in voor een sync tijdens boot. Zet de synctime optie uit en draai dus ntpd.

Dat raadt VMware tegenwoordig zelf ook aan als 'best practice'.

Waar kan dit precies? Ik vind vooral oplossingen voor ESX lijkt het.
Ga trouwens dan denk ik maar zonder SMP draaien, dat schijnt ook al te schelen.

[wzzrd]

/etc/ntp/step-tickers op een RHEL doos. Weet niet waar het op BSD staat.

[capedro]

* capedro heeft ook een soortgelijk probleem gehad...

achteraf gezien bleek er geen

code:

/dev/rtc

aanwezig te zijn op de (Gentoo based) host. Na een recompile van de kernel werkte alles naar behoren.

[Boudewijn]

Hmm zal eens kijken of ik die in debian wel heb, want het is echt vrij irritant en onhandig.

[Theraven1982]

al geprobeerd om APIC uit te zetten (in /boot/loader.conf):

hint.apic.0.disabled=1

en dan een reboot; heeft wel eens voor mij gewerkt als ik het me goed herinner

Dit omzeilen dmv NTP is in ieder geval niet de juiste manier; idd beter de oorzaak ipv de gevolgen aan pakken.

[ Voor 25% gewijzigd door Theraven1982 op 19-09-2008 18:35 ]

[Verwijderd]

Xen had/heeft het zelfde probleem. Dit kon je verhelpen door een sysctl setting die er voor zorgt dat de guest de tijd/datum van het host systeem gebruikt en geen eigen time counters bijhoudt. Gezien Xen is overgenomen door VMWare is er misschieen een vergelijkbare oplossing.

[Boudewijn]

apic uitzetten werkt dus niet.
Ondertussen naar vmwareserver 2 rc2 gegaan.

/dev/rtc bestaat in het host os.

@sorcerer, weet je nog welke setting dat is geweest?

Ik heb trouewns een helemaal schone vm gepakt.
Als je top draait, zie je gewoon maar 1x per 3-5 seconden oid de tijd geupdate worden (met 1 seconde...).

[Boudewijn]

Voor het nageslacht:

De combinatie werkt met:

FreeBSD-7
Vmware server 2 RC2.
kern.hz="100" in loader.conf
"Synchronize guest os met host os" in vmware.


Ding draait nu alweer een nachtje als een trein, klopt allemaal exact .