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:
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:
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):
Ergänzend die Übersicht aus Proxmox:
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 ?
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.
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
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:
- Mainboard: Supermicro MBD-X13SRA-TF
- CPU: Intel Xeon w5-2465X
- RAM: entsprechend der Vorgaben von Supermicro: DDR5 4800MHz CL40 ECC
- PCIe Devices: Adaptec Raidcontroller, keine weiteren Geräte
- Proxmox Version 8.0.4 Kernelversion
pve-manager/8.0.4/d258a813cfa6b390 (running kernel: 6.2.16-15-pve)
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:
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-b4490c57a22cErgänzend die Übersicht aus Proxmox:
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.comDie 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
