Skok systémového času Windows

Re:Skok systémového času Windows
« Odpověď #15 kdy: 07. 01. 2026, 13:14:52 »
Teď už zbývá jenom zjistit proč to dělá.
Přepdokládám, že proto, že máte zapnutou synchronizaci času s hostitelem, jak psal Marvin. A ty časové skoky by pak byly způsobené tím, že má špatně nastavený čas hostitel – jak psal František Ryšánek, je potřeba zkontrolovat, zda hypervizor má správný čas, a zda má nějaký mechanismus, jak čas udržovat správný (např. z NTP).

Pokud to tak je, u vás by se problém vyřešil tím, že vypnete synchronizaci času s hostitelem a necháte Windows, ať se o čas starají na základě NTP (tj. to standardní nastavení, které vám ráno nastavuje zpět správný čas). Nicméně chtělo by to vyřešit správný čas i na tom hypervizoru, protože dneska mít někde špatný čas je celkem nebezpečné (jsou z toho různé podivné chyby) a v drtivé většině případů zbytečné (pokud nemáte počítač v bunkru pod zemí odpojený od sítě, vždycky se aspoň nějaký zdroj přesného času dá sehnat).

A až bude vyřešen problém se synchronizací času v hypervizoru, rozhodněte se, který ze způsobů synchronizace času chcete použít, a použijte jenom jeden. Buď vlastí synchornizaci v hostovaném systému (Windows) nejspíš přes NTP, nebo synchornizaci času s hypervizorem. Protože ještě horší, než mít špatný čas, je mít špatný čas pokaždé jinak, podle toho, který zdroj času zrovna vyhraje.


Re:Skok systémového času Windows
« Odpověď #16 kdy: 07. 01. 2026, 13:16:08 »
"Synchronize guest time with host" je zapnuto nebo vypnuto?
Těď jsem ji ve virtuálce vypnul. Uvidím zítra, jestli to pomůže
Kód: [Vybrat]
VMwareToolboxCmd.exe timesync disableBohužel jsem se nepodíval předtím na status jestli byla zapnuta nebo nikoliv. Předpokládám ale, že byla. Napsal jsem správci aby sycnchronizaci vypnul v host systému v konfiguraci virtuálky než se přijde na příčinu.

Nedočetl jsem se důležitou informaci: máte důvod se domnívat, že ten VMware (hypervizor) má správný čas?
Díval jste se? Bere si ho odněkud přes NTP?

To je velmi dobrá připomínka, zeptám se správce.

Vrtá mi hlavou, jestli Vám tam běží nějaký další nespecifikovaný software, zda se třeba nesnaží ještě taky po svém zasahovat do systémového času - to už je na Vás.
Našel jsem zásahy jenom od zmíněného wmtoolsd a pak korekce zpět (a případné běžné korekce v řádu milivteřin) od w32tm


Re:Skok systémového času Windows
« Odpověď #17 kdy: 07. 01. 2026, 15:11:44 »
Pro doplnění, v jiné virtuálce se to děje taky. Fyzické železo je Dell Poweredge R350 a běží na něm ESXi.

Re:Skok systémového času Windows
« Odpověď #18 kdy: 07. 01. 2026, 16:17:40 »
Já myslím, že jste na správné cestě. Vlastně píšu jenom abych přidal dva odkazy na související čtení v Meinbergovic knowledgebase, ohledně VMware:
[1]
[2]
Ale v podstatě se tam k tématu této debaty už nedočtete nic moc nového... nad rámec těch pár bodů, které už tu zmínili předřečníci.
(Upozornění na lehký střet zájmů: značka Meinberg mě živí.)

Re:Skok systémového času Windows
« Odpověď #19 kdy: 08. 01. 2026, 09:59:00 »
Ale ten Váš timesynctool bude také citelně méně složitý na konfiguraci, než zmíněné "seriózní" servisky.

Ono je na
W32tm /config /syncfromflags:MANUAL /manualpeerlist:cz.pool.ntp.org
eventuálně pokud je stroj v AD doméně /syncfromflags:DOMHIER
W32tm /config /update
W32tm /resync
něco složitýho?
« Poslední změna: 08. 01. 2026, 10:00:53 od Marek Staněk »


Re:Skok systémového času Windows
« Odpověď #20 kdy: 08. 01. 2026, 15:28:51 »
Tak bohužel, i když
Kód: [Vybrat]
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe timesync status
Disabled
Stejně došlo ke skoku. Dneska ve 3:18 v noci skok 2772185ms a v 8:01 to w32tm srovnal zpět, skok -2772046 ms.

Kód: [Vybrat]
Systémový čas se změnil z ?2026?-?01?-?08T02:18:27.473475100Z.
na ?2026?-?01?-?08T03:04:39.659000000Z: 2772185 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Program Files\VMware\VMware Tools\vmtoolsd.exe' (PID 4192).

Čas RTC: ?2026?-?01?-?08T04:04:39.659000000Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false
Kód: [Vybrat]
Systémový čas se změnil z ?2026?-?01?-?08T07:47:25.565543200Z.
na ?2026?-?01?-?08T07:01:13.519251600Z: -2772046 ms

Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Windows\System32\svchost.exe' (PID 1472).

Čas RTC: ?2026?-?01?-?08T08:01:13.519251600Z
Aktuální posun časového pásma:  -60
Čas RTC je ve formátu UTC: false
Systémový čas byl založen na času RTC: false

Teď jsem navíc mluvil se správcem a říkal že ve všech virtuálkách je synchronizace přes VMWare Tools vypnuta. Že se na to ješte zkusí podívat, případně zkusit aktualizovat verzi VMWare Tools (ve virtuálce běží asi 2,5 roku stará verze, co běží v ESXi nevím). Nevím jestli třeba nesoulad verzí host/guest může toto způsobit..

Vážně uvažuju o vypnutí vmtoolsd než se to dořeší, ať nešahá na čas. Může to způsobit nějaké závažnější problémy?

Re:Skok systémového času Windows
« Odpověď #21 kdy: 08. 01. 2026, 16:40:28 »
Dle dokumentace timesync disable vypne periodickou synchronizaci, ale ne změnu na základě eventů.

Citace
...
These options do not disable one-time synchronizations done by VMware Tools for events such as tools startup, taking a snapshot, resuming from a snapshot, resuming from suspend, or vMotion. These events synchronize time in the guest operating system with time in the host operating system even if VMware Tools periodic time sync is disabled, so it is important to ensure that the host operating system's time is correct.

Zapl jsem ješte logování v VMWare Tools na úrověn debug a uvidím, co mě překvapí zítra.

Re:Skok systémového času Windows
« Odpověď #22 kdy: Dnes v 07:16:53 »
Tohle váš problém nevyřeší, ale není od věci ve Windows nastavit systémový čas na UTC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
(nutný restart)

Pak tam nebudou žádné posuny o 3600.
V případě dual boot je to skoro nezbytné.

Re:Skok systémového času Windows
« Odpověď #23 kdy: Dnes v 09:02:22 »
Citace
Pak tam nebudou žádné posuny o 3600.
Tady je skok o 2777, na časové pásmo to nevypadá.
Standardní ntpd skoky nad 1000 vůbec nedělá, čeká na ruční zásah.
W32Time má na skoky limity MaxPosPhaseCorrection a MaxNegPhaseCorrection, ale defaultně nejsou nastaveny.

Re:Skok systémového času Windows
« Odpověď #24 kdy: Dnes v 09:34:42 »
Tohle váš problém nevyřeší, ale není od věci ve Windows nastavit systémový čas na UTC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
(nutný restart)

Pak tam nebudou žádné posuny o 3600.
V případě dual boot je to skoro nezbytné.
Tohle nastavení by mělo být shodné s tím, v jakém časovém pásmu poskytuje čas hypervizor. Pokud hypervisor poskytuje hostovi čas v UTC, mělo by to být nastavené, jak píšete. Pokud hypervizor poskytuje lokálí čas, měla by tam být výchozí hodnota.

Každopádně tohle ovlivňuje, jak se čas načte ze systémových hodin při startu systému. Pak naběhnou služby a ty to srovnají buď podle NTP, nebo podle hypervizora (pokud se používá ta služba z VMware Tools).

(Když běží systém nafyzickém železe, ovlivňuje výše uvedené samozřejmě i zpětný zápis, když operační systém zapíše svůj čas zpátky do hodin počítače. Ve virtualizovnaém prostředí to ale nemá žádný efekt – nevím o tom, že by nějaká virtualizační technologie udržovala systémové hodiny pro každého hosta zvlášť.)

Re:Skok systémového času Windows
« Odpověď #25 kdy: Dnes v 10:29:15 »
Citace
Pak tam nebudou žádné posuny o 3600.
Tady je skok o 2777, na časové pásmo to nevypadá.
Standardní ntpd skoky nad 1000 vůbec nedělá, čeká na ruční zásah.
W32Time má na skoky limity MaxPosPhaseCorrection a MaxNegPhaseCorrection, ale defaultně nejsou nastaveny.

Teď mi vlastně došlo, že tohle se nám vloni na jaře dělo u jednoho zákazníka, kde časový server pro telefonní subsystém (tzn ústředna, TSAPI server, telefonní přístroje, nahrávače) zničeho nic začal ze svého časového normálu dostávat periodicky chybná data. Zhruba každých 7 hodin prostě dostal chybný čas, takže všechno na něj navázané se po náhodné prodlevě přeštelovalo, takže třeba párování záznamů hovorů bylo pro období asi měsíce naprostý peklo. Nakonec se ukázalo, že služba NTP démona na nějakém síťovém prvku po nějakém uptimu (nehorázná doba, asi 7 let) začala magořit a restart ji "opravil". Prostě jí něco někde přeteklo.
Takže ten problém klidně může být někde, kam nedohlídneš.

Zkus ty postižené virtuály nastavit proti cz.pool.ntp.org (viz výše).