Windows Server 2022 Standard konstanter Zeitversatz

Makky227

New Member
Oct 17, 2023
9
0
1
Guten Morgen,

ich arbeite zurzeit an der Einrichtung eines Proxmox Hosts für mehrere Instanzen von Windows Server 2022 Standard. Die Einrichtung an sich lief problemlos, der Betrieb ist jedoch fast nicht möglich, aufgrund eines konstanten Zeitversatzes in den einzelnen VMs. Das Problem trat schon ziemlich häufig hier auf, aber ehrlich gesagt, bin ich etwas ratlos, was ich noch versuchen soll...

Wie wurde vorgegangen / wie war der Ablauf ?

Installation und Einrichtung von Proxmox:

Dies verlief problemlos. Der Host verwendet folgende Hardware/Software:
  1. Mainboard: Supermicro MBD-X13SRA-TF
  2. CPU: Intel Xeon w5-2465X
  3. RAM: entsprechend der Vorgaben von Supermicro: DDR5 4800MHz CL40 ECC
  4. PCIe Devices: Adaptec Raidcontroller, keine weiteren Geräte
  5. Proxmox Version 8.0.4 Kernelversion pve-manager/8.0.4/d258a813cfa6b390 (running kernel: 6.2.16-15-pve)
Alles wurde perfekt erkannt und stand nach der Installation auch direkt zur Verfügung. DNS und feste IP Adressen im Server eingetragen, Uhrzeiten im BIOS, IPMI und Proxmox überprüft -> fertig.

Einrichtung der ersten VMs:

Im Anschluss wurde begonnen, die ersten Windows Server 2022 VMs einzurichten. Ich habe mir ein Template angelegt, damit ich etwas Zeit spare (wird später noch wichtig). Drei Instanzen eingespielt (Domaincontroller DC2, Fileserver und 3CX -> 3CX wird ebenfalls später wichtig). Der DC2 (nennen wir ihn mal so) wurde erstmal parallel zu einem anderen DC1 betrieben, der nicht auf Proxmox läuft, aber halt abgelöst werden sollte.

Nach einem Wochenende kamen dann die ersten Beschwerden, dass die Telefonate über die 3CX verzöget wären und die Audioqualität allgemein sehr schlecht ist. Mir ist dann aufgefallen, dass in der Instanz von Windows Server, auf der die 3CX gehostet wurde, die Uhrzeit komplett falsch lief (Alle drei Instanzen waren in der Domain, die PDC Rolle wurde aber NICHT von der DC1 VM auf die neue DC2 VM auf Proxmox übernommen. Die Umstellung fehlte noch.) Mit anderen Worten, der Zeitabgleich vom anderen DC1 auf die drei VMs funktionierte nicht durchgehend. Ein manueller Abgleich funktionierte, aber die Zeit hing sofort nach. Die Uhrzeit auf dem bereits bestehenden DC1 war auf die Sekunde genau. Alle Clients hatten auch die korrekte Zeit, nur die drei VMs nicht.

Als Maßnahme habe ich dann auf der neuen VM für den DC2 einen NTP Server eingerichtet und entsprechend eingestellt, dass er nicht mehr die Zeit vom DC1 bezieht. Gleiches Resultat, die Uhrzeit wird synchronisiert, läuft direkt nach. Mit viel Geduld habe ich dann einen Versatz von +1min geschafft, nachdem wieder synchronisiert wird und die Zeit auch für 1 Sekunde stimmt, was aber meiner Meinung nach immer noch schlecht ist, denn die 3CX arbeitet so nicht mehr richtig. Wird die PDC Rolle auf den neuen DC2 auf Proxmox übertragen, wo auch der NTP Server läuft, erhalten auch alle anderen Clients eine falsche Uhrzeit -> logisch. Das Problem mit der 3CX kam in der Tat von diesem Zeitversatz. Anderer Host, perfekte Uhrzeit, Gespräche wieder normal und nicht mehr verzerrt. Die Einstellungen an sich waren auch korrekt: Der DC2 verwendete den NTP Server, alle Clients den DC1 und nach Übertragung der PDC Rolle, zum Testen, dann auch den DC2. DC1 hat immer die korrekte Zeit, der DC2 haut nach dem Systemstart, wie alle anderen VMs, direkt ab. (Siehe cmd Output unten)

Nun vielleicht liegt es am Template ? Um das zu testen habe ich eine neue VM komplett von Grund auf eingerichtet, Qemu Guest Agent + alle Treiber erneut installiert. Die VM wurde nicht in die Domain eingebunden -> gleiches Resultat. Die VM startet mit der richtigen Uhrzeit und driftet direkt ab. Ich habe die Abweichung in den VMs mal gegen einen Zeitserver dargestellt:

Screenshot 2023-10-17 110541.png

Das ist so mehr oder weniger das Verhalten, wie es auf allen VMs ist. Diese Abweichung ist noch gering, in anderen VMs beträgt diese teilweise bis zu 5 Minuten, wenn ich nichts mache, sogar noch mehr (teilweise Stunden)

Dann habe ich alle Variationen der VM Config getestet: Kein Qemu Guest Agent, mit Agent, Use Local Time for RTC (Default, Yes, No), anderes Bios, andere Maschine, diverse CPU Modelle, ...

Hier mal die Config von der zuletzt erstellen VM ohne irgend welche Extras im Betriebssystem (NTP, Domainzugriff, etc.), blanke VM (Installiert, Adminpasswort festgelegt, eingeloggt, Zeit driftet direkt ab):

Code:
acpi: 1
agent: 1
balloon: 4096
bios: ovmf
boot: order=scsi0
cores: 1
cpu: x86-64-v2-AES
efidisk0: local-btrfs:100/vm-100-disk-0.raw,efitype=4m,pre-enrolled-keys=1,size=528K
machine: pc-q35-8.0
memory: 6144
meta: creation-qemu=8.0.2,ctime=1697460137
name: WinServer2022-Test
net0: virtio=DE:DC:BD:19:CA:81,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsi0: local-btrfs:100/vm-100-disk-1.raw,discard=on,iothread=1,size=32G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=0f26a61d-ded5-4d84-9539-b8bf2c1771b9
sockets: 1
vmgenid: 945bfe6b-46d0-4513-80ba-b4490c57a22c

Ergänzend die Übersicht aus Proxmox:

Screenshot 2023-10-17 111100.png

Screenshot 2023-10-17 111040.png

Wie sieht es in der Zwischenzeit mit dem Proxmoxhost aus ? Immer noch korrekte Uhrzeit, NTP Server können alle korrekt aufgelöst werden, sowohl in Proxmox als auch in den VMs selbst. DC1 und DC2 beziehen die Zeitdaten von NTP Servern, so wie eingestellt, laufen aber direkt wieder weg.

Läuft chronyd ?

Code:
root@pve:~# systemctl status chronyd
● chrony.service - chrony, an NTP client/server
     Loaded: loaded (/lib/systemd/system/chrony.service; enabled; preset: enabled)
     Active: active (running) since Mon 2023-10-16 22:04:23 CEST; 13h ago
       Docs: man:chronyd(8)
             man:chronyc(1)
             man:chrony.conf(5)
    Process: 6287 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=exited, status=0/SUCCESS)
   Main PID: 6289 (chronyd)
      Tasks: 2 (limit: 76637)
     Memory: 2.3M
        CPU: 61ms
     CGroup: /system.slice/chrony.service
             ├─6289 /usr/sbin/chronyd -F 1
             └─6290 /usr/sbin/chronyd -F 1

Oct 16 22:04:23 pve systemd[1]: Starting chrony.service - chrony, an NTP client/server...
Oct 16 22:04:23 pve chronyd[6289]: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Oct 16 22:04:23 pve chronyd[6289]: Frequency -41667.510 +/- 0.872 ppm read from /var/lib/chrony/chrony.drift
Oct 16 22:04:23 pve chronyd[6289]: Using right/UTC timezone to obtain leap second data
Oct 16 22:04:23 pve chronyd[6289]: Loaded seccomp filter (level 1)
Oct 16 22:04:23 pve systemd[1]: Started chrony.service - chrony, an NTP client/server.
Oct 16 22:04:28 pve chronyd[6289]: Selected source 217.91.44.17 (0.pool.ntp.org)
Oct 16 22:04:28 pve chronyd[6289]: System clock TAI offset set to 37 seconds
root@pve:~# chronyc online
200 OK


root@pve:~# chronyc ntpdata

Remote address  : 188.68.36.203 (BC4424CB)
Remote port     : 123
Local address   : 192.168.0.240 (C0A800F0)
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 2
Poll interval   : 10 (1024 seconds)
Precision       : -23 (0.000000119 seconds)
Root delay      : 0.009949 seconds
Root dispersion : 0.012100 seconds
Reference ID    : C035676C ()
Reference time  : Tue Oct 17 08:56:33 2023
Offset          : +0.000545968 seconds
Peer delay      : 0.012032043 seconds
Peer dispersion : 0.000000144 seconds
Response time   : 0.000085505 seconds
Jitter asymmetry: +0.00
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX        : 72
Total RX        : 72
Total valid RX  : 72
Total good RX   : 72

Remote address  : 162.159.200.123 (A29FC87B)
Remote port     : 123
Local address   : 192.168.0.240 (C0A800F0)
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 3
Poll interval   : 10 (1024 seconds)
Precision       : -25 (0.000000030 seconds)
Root delay      : 0.008087 seconds
Root dispersion : 0.000275 seconds
Reference ID    : 0AD60806 ()
Reference time  : Tue Oct 17 09:02:17 2023
Offset          : -0.000357023 seconds
Peer delay      : 0.009705641 seconds
Peer dispersion : 0.000000055 seconds
Response time   : 0.000071245 seconds
Jitter asymmetry: +0.00
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX        : 88
Total RX        : 84
Total valid RX  : 84
Total good RX   : 58

Remote address  : 131.188.3.221 (83BC03DD)
Remote port     : 123
Local address   : 192.168.0.240 (C0A800F0)
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 1
Poll interval   : 9 (512 seconds)
Precision       : -21 (0.000000477 seconds)
Root delay      : 0.000000 seconds
Root dispersion : 0.001175 seconds
Reference ID    : 44434670 (DCFp)
Reference time  : Tue Oct 17 09:09:45 2023
Offset          : +0.000871748 seconds
Peer delay      : 0.032896850 seconds
Peer dispersion : 0.000000505 seconds
Response time   : 0.000076350 seconds
Jitter asymmetry: +0.00
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX        : 88
Total RX        : 88
Total valid RX  : 88
Total good RX   : 86

Remote address  : 217.91.44.17 (D95B2C11)
Remote port     : 123
Local address   : 192.168.0.240 (C0A800F0)
Leap status     : Normal
Version         : 4
Mode            : Server
Stratum         : 2
Poll interval   : 10 (1024 seconds)
Precision       : -23 (0.000000119 seconds)
Root delay      : 0.000427 seconds
Root dispersion : 0.000305 seconds
Reference ID    : C0A8640F ()
Reference time  : Tue Oct 17 09:01:57 2023
Offset          : +0.001673619 seconds
Peer delay      : 0.018917019 seconds
Peer dispersion : 0.000000145 seconds
Response time   : 0.000049378 seconds
Jitter asymmetry: +0.00
NTP tests       : 111 111 1111
Interleaved     : No
Authenticated   : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX        : 72
Total RX        : 72
Total valid RX  : 72
Total good RX   : 72


root@pve:~# chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- rondra.lf-net.org             2  10   377   782   -367us[ -546us] +/-   23ms
^+ time.cloudflare.com           3  10   377   688   +357us[ +357us] +/- 9171us
^+ ntp1.rrze.uni-erlangen.de     1   9   377   237   -872us[ -872us] +/-   18ms
^* www.kashra.com

Die Frage würde ich mit Ja beantworten.

Firewall ?

Die wurde zum Testen komplett rausgenommen.

Dann habe ich mir nochmal die VMs vorgenommen: Dort ist mir in der Registry aufgefallen, dass in der Hardware der erste Kern (Core 0) ~200MHz zu wenig hatte. Da es nur eine Anzeigegeschichte war, habe ich im BIOS nach entsprechenden Einstellungen geschaut und dort alle Energiesparmaßnahmen ausgeschaltet, die ich finden konnte.
Nun werden für alle die erwarteten 3100MHz angezeigt, was aber nichts gebracht hat, der Versatz ist immer noch vorhanden. In diesem Zusammenhang wurde auch der von Supermicro empfohlene Precision Event Timer im BIOS überprüft. Der war bereits standardmäßig auf "Enabled".

Es laufen drei Ubuntu VMs auf Proxmox, die haben das Problem nicht.

Nun andere Hardware: Ich habe noch einen Proxmox bei mir laufen -> gleiches Iso der Windows Server Installation installiert -> Benutzer eingerichtet -> angemeldet -> Zeit läuft perfekt synchron. pve-manager/8.0.4/d258a813cfa6b390 (running kernel: 6.2.16-10-pve)

Was mir spontan noch einfällt ist ein BIOS Update, wobei ich da wenig Hoffnung habe. Supermicro ist, was Changelogs angeht, etwas zurückhaltend. Das Update wird jedoch erst am Wochenende durchführbar sein.

Ich bin ehrlich gesagt mit meinem Latein am Ende und demnach etwas planlos, was ich noch versuchen könnte. Der Post wurde sogar so lang, dass ein Guten Morgen schon fast nicht mehr reicht... Hoffe, das ist okay...

Grüße Makky227
 
Hi, ich glaube nicht das es hilft, aber stelle die VM CPU mal auf host. Ich habe sogar Probleme bei 2022 mit der installation, wenn ich die auf default KVM lasse.
 
Hello, danke für die schnelle Antwort. host habe ich tatsächlich schon öfters versucht, war aber immer das gleiche Resultat. Was aber komisch ist: Ich habe gerade mal von x86-64-v2-AES bzw. host auf kvm64 gestellt und die Zeit auf meiner Test-VM ist so wie sie sein soll...
Den virtualisierten Domaincontroller habe ich ebenfalls mal umgestellt, aber da keine Änderung.

[EDIT]: Seltsam ist auch, dass ich das nicht reproduziert bekomme. Die Test-VM funktioniert nach der Umstellung quasi immer, egal, was ich an CPU Typ einstelle. Installiere ich von Grund auf genau die gleiche VM als zweiten Test, ist das Problem auch wieder da. Da hilft auch eine Änderung vom CPU Typ nicht mehr.
 
Last edited:
Gibt es eine Änderung, wenn Du in den Options der VMs "Use local time for RTC" von "Default" explizit auf "Yes" umstellst?
 
nein leider nicht. Da habe ich alle drei Optionen schon durchprobiert.

Ich bin mir ehrlich gesagt nicht sicher, wo die Ursache liegen soll (also Windows oder Proxmox). Von der VM, die nun funktioniert, habe ich einen Snapshot gemacht und als neue VM wiederhergestellt. Die funktioniert auch wie sie soll. Eine neue VM mit 1:1 den gleichen Einstellungen hat das gleiche Problem.
 
Hi!
Kannst du zum testen mal eine VM mit dem Linux Image von 3CX installieren? Vollständiges Backup der laufenden 3CX lässt sich dort wieder einspielen und du kannst direkt loslegen. Die IP Konfig kann ja direkt identisch sein solange die nicht gleichzeitig in Betrieb sind.
Trotzdem habe ich die Vermutung, das es innerhalb des Netzwerkes zu Verzögerungen kommt. Normalerweise gleicht das NTP das ja schon aus, aber.....
SIP ALG überall deaktiviert?
 
Also das mit der 3CX ist allgemein kein Problem, solange die eben nicht auf Proxmox läuft. SIP ALG ist überall deaktiviert. Als ich die 3CX auf der Proxmox VM eingerichtet, bzw. die Sicherung wiederhergestellt hatte, war der Firewallcheck auch grün. Wenn ich es richtig im Kopf habe, meckert die Anlage dort sofort. Die Anlage lief in der Konfiguration seit Monaten problemlos.

[EDIT]: Also in der Konfiguration als VM auf einem Hyper-V Host, nicht auf Proxmox.

Der Ausgleich über NTP funktioniert auch, aber eben nicht schnell genug (?). So, wie ich es verstanden habe, wird eine korrekte Zeit beim Start einer VM gesetzt. Danach übernimmt die VM selbst. Ab dann geht's den Bach runter. Pro Sekunde sind es ~10-30ms, wo die Uhr hinterherhängt (manchmal mehr und manchmal weniger). Wenn die VM richtig mitzählt sind es vielleicht Mikrosekunden. Die Abweichungen summieren sich auf und durch NTP wird nachgeregelt, wenn die Differenz zu groß ist. Nur bei der ersten Abweichung kommt er anscheinend nicht hinterher, bzw. es geht direkt wieder von vorne los.

Offtopic: Was auch noch eine Sache war: Seit kurzem arbeitet 3CX mit Split DNS, da kann es zu erheblichen Zeitversätzen kommen, wenn der DNS eben nicht richtig konfiguriert ist (also außerhalb FQDN auf die Static IP und innerhalb eben auf die interne IPv4 und IPv6). Das habe ich aber überprüft und läuft einwandfrei.
 
Last edited:
Kannst du auf dem Host im Bios mal die C-States deaktivieren, normalerweise sollte im Windows die Energieeinstellung auf Höchstleistung den gleichen Effekt haben.
 
Kannst du auf dem Host im Bios mal die C-States deaktivieren, normalerweise sollte im Windows die Energieeinstellung auf Höchstleistung den gleichen Effekt haben.
Das ist bereits geschehen. Alles, was irgendwie mit Energiesparmaßnahmen zu tun hatte, habe ich im BIOS deaktiviert. Die C-States konnte ich nur auf C0 / C1 begrenzen, was aber ausreichen sollte.
Energieoption in Windows selbst stehen alle auf Höchstleistung
Ich glaube wir sollten lieber die Ursache finden und nicht die Symptome bekämpfen. Normal ist eine solche Timedrift nicht.
Da würde ich mich anschließen. Zusätzliche Tools würde ich gerne vermeiden, zumal es ja einfach bei einer VM funktioniert, selbst wenn diese VM in der Domain ist. Wenn ich diese VM repliziere, funktionieren die Kopien ebenfalls. Da kann ich auch die Einstellungen ändern, wie ich möchte (CPU=HOST, x86-x64-AES, kvm64,...) da ändert sich nichts mehr.

[EDIT]: Mir ist ebenfalls aufgefallen, dass Windows 10 das gleiche Problem haben kann. Auf einem anderen Gerät (andere Hardware) funktioniert alles wieder so, wie es soll.
 
Last edited:
okay das ist interessant. Den Command im ersten Link hatte ich bereits schonmal verwendet, aber ohne Erfolg...

Ich habe zum Testen eine komplett neue VM mit Windows Server 2022 erstellt. Der Befehl aus dem ersten Link hat dort nun Abhilfe geschaffen. Die VM ist jetzt mal noch nicht in der Domain, aber das wird noch getestet.
Um das generell nochmal zu testen, habe ich das Vorgehen erneut durchgeführt, wobei das Ergebnis gleich war. Standardmäßig fehlt der Eintrag in bcdedit komplett.

Mir stellt sich nun die Frage, welche Systemclock das nun ist. Wird die durch Proxmox (chrony.d) vorgegeben oder kommt die vom BIOS ? Wenn das von Proxmox selbst kommt, kann ich mir direkt erklären, warum es zuvor nie funktioniert hat.
 
Das war tatsächlich nicht das Problem. Die Synchronisation der Zeit funktionierte, aber der Drift war stets zu groß. Der Abgleich vom DC mit einem NTP Server funktionierte, auch, dass die Domainclients den DC als Zeitquelle kannten, funktionierte ohne Probleme, auch ohne GPO. Die Zeit auf dem DC und den anderen VMs ist nur deutlich langsamer gelaufen, als es sollte. Nach jeder Sekunde ist die Zeit eben um ein bestimmtes Maß "zurückgefallen".

Mit der Anpassung in bcdedit funktionierts nun. Alle Zeiten bleiben so, wie sie sollen und die Clients laufen auch alle synchron mit. Was ich an dieser Stelle noch nicht verstehe ist, warum andere VMs auf anderer Hardware diese Anpassung nicht brauchen.
 
Auf was für einer Hardware liefen die VMs vor der Migration? Eventuell ist beim installieren etwas konfiguriert worden was nach dem Migrieren anders benötigt wird. Einige Sachen laufen bei Windows recht intransparent.
 
Auf keiner, das waren alles neu aufgesetzte VMs. Ich habe die andere Hardware parallel zum Testen verwendet, weil ich erst die Hardware im Verdacht hatte.
 
Dann ist das Phänomen echt komisch. Sollte so nie auftauchen und habe ich bisher auch noch nicht gesehen.
 
Ich kann es mir leider auch nicht wirklich erklären. Der einzige Unterschied liegt nun in der Hardware und eben in der einen Ergänzung in bcdedit.
Meine Vermutung, warum es vorher mit der Ergänzung nicht funktionierte, liegt in chrony.d. Der Service lief zwar, aber auch nicht richtig. Wenn der Dienst die Clock für die VMs vorgibt, konnte es vorher nicht funktionieren (natürlich unter der Voraussetzung, dass ich das System so richtig verstanden habe).

Vielleicht findet man die Erklärung dafür irgendwann mal noch.

Auf jeden Fall danke an alle. Wahrscheinlich wäre ich immer noch am suchen.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!