Seit Kurzem permanent perfmon Logs

[dev0]

Ich kann Dir, in einer VMWare Umgebung, auch nur empfehlen die Zeit der VMs nicht mit dem Host, sondern mit dem typischen Mechanismus der Betriebssysteme zu synchronisieren. Ich hatte selbst vor 4-5 Jahren bei einem internationalem Kunden größte Probleme die Zeitsynchronisierung in den Griff zu bekommen, da die Konfiguration der VM Hosts nicht unter unserer europäischen Hoheit lag.

In jedem Fall für Linux einen (zentralen) ntp Server und nicht den die Synchronisierung mit dem Host nutzen. Wenn die VMWare Tools installiert sind, dann sollten mit aktuellen Betriebssystemen auch keine Anpassungen mehr nötig sein.

Just my 2 cents...

[vbs]

Ja hab ich bei mir auch so eingerichtet. Aber ich glaube, dass in meinem Fall gar nicht die Zeitsynchronisierung selbst das Problem ist, sondern dass einfach die System-Uhr der VM viel zu langsam läuft (ungefähr 1 Minute in 10 Stunden). Normale kleine Unterschiede könnte ntpd wohl ausgleichen aber nicht in diesen Dimensionen.

[vbs]

Hm, also es ist komisch. Aber vorweg, das sieht jetzt (im Moment) so aus:

Code Auswählen Erweitern

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
0.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
1.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
2.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
3.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
ntp.ubuntu.com  .POOL.          16 p    -   64    0    0.000    0.000   0.000
-62.4.12.66      145.238.203.14   2 u  128 1024  377   25.040    0.704  12.100
*hetzner0.intern 194.97.129.17    2 u  597 1024  377   20.077    1.716  13.263
-tartaros.dust-p 126.94.231.148   2 u  580 1024  377   21.429    2.237  13.428
+ntp1.m-online.n 212.18.1.106     2 u   53 1024  377   48.820   -8.851  10.319
+totoro.ax86.net 36.224.68.195    2 u  586 1024  377   18.389    1.482  13.533
Meiner Meinung nach traumhaft Werte, also erstmal gut

Aber so ganz trau ich dem Braten noch nicht. Was ich gemacht habe:
- ich hab wie beschrieben (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1011771) den timeTracker aktiviert, der hat jedoch keine Fehler gezeigt (immer "behind 0 us")

- dann hab ich wie hier beschrieben (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1591) "noTSC" in die config.ini eingetragen und dann waren die Werte gut. Aber ich hab dann das noTSC testweise als Gegenprobe wieder rausgenommen und es war immer noch gut 

Also das war so
- VM runtergefahren
- noTSC -> config.ini
- VM hochgefahren
-> Zeit war gut
- VM runter gefahren
- noTSC wieder rausgenommen
- VM hochgefahren
-> Zeit immer noch gut (??)
- Host-PC rebootet
-> Zeit wieder schlecht (??)
- VM runter
- wieder noTSC eingetragen
- VM hoch
-> Zeit wieder gut
- Host-PC rebootet
-> Zeit immer noch gut

Sah aus als ob das Setzen von noTsc greift sobald man nur die VM rebootet, das Ausschalten jedoch ein Reboot des Host-PC erfordert 

Lange Rede, kurzer Sinn: mit dem noTsc gehts jetzt. Da das Verhalten für mich nicht so 100% konsistent ist, habe jedoch noch etwas Rest-Angst, dass das noch nicht die ganze Geschichte war.

Weiß jemand ob dieses noTsc irgendwelche Nachteile hat? Kommt mir auch etwas spanisch vor, dass man einfach diese Traumwerte bekommt wenn man es setzt? Muss doch einen Grund geben, warum das nicht defaultmäßig gesetzt ist?

Danke euch!