Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: jardaplc 06. 01. 2026, 11:21:56
-
Zdravím,
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět. (Přesné časy skoků bych mohl dohledat z logů).
Nejsem správce fyzického železa, ale mluvil jsem s ním, říkal že nic neměnil a že se na to podívá.
Dávám to sem ze zajímavosti, jestli jste se taky setkali s něčím podobným.
Pro úplnost když jsem přišel na tento problém, zapl jsem w32tm stripchart a tady jsou částečné logy:
w32tm /stripchart /computer:pool.ntp.org /dataonly /period:300 |
>> Tee-Object -FilePath C:\temp\time_drift_2.log -Append
Tracking pool.ntp.org [162.159.200.123:123].
The current time is 05.01.2026 14:25:18.
14:25:18, +00.0129176s
14:30:18, +00.0165300s
14:35:18, +00.0193773s
14:40:18, +00.0223993s
14:45:18, +00.0199100s
14:50:18, +00.0091434s
...
02:55:21, +00.0417110s
03:00:21, +00.0433553s
03:05:21, +00.0433707s
03:10:21, +00.0450076s
03:15:21, +00.0482284s
04:06:34, -2773.7582560s
04:11:34, -2773.7540893s
04:16:34, -2773.7542422s
04:21:35, -2773.7517265s
04:26:35, -2773.7467640s
04:31:35, -2773.7460565s
...
07:26:35, -2773.6656590s
07:31:35, -2773.6626884s
07:36:35, -2773.6611551s
07:41:35, -2773.6579177s
07:00:21, +00.0128807s
07:05:21, +00.0164778s
07:10:21, +00.0196563s
07:15:21, +00.0216492s
07:20:21, +00.0116391s
Status w32tm:
PS C:\Users\xxx> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 2 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0006809s
Root Dispersion: 10.1682249s
ReferenceId: 0xC0A8C814 (source IP: 192.168.200.20)
Last Successful Sync Time: 06.01.2026 10:57:53
Source: xxxx.yyyy.local
Poll Interval: 12 (4096s)
xxxx.yyyy.local je stroj v lokální síti, ale tam běží čas normálně, spustil jsem stripchart i proti němu a výstup byl stejný jako proti pool.ntp.org. A začalo se to dít 29.12, předtím se to nejspíš nedělo. Ale shodou okolností tam běží něco, co generuje periodické logy každých 5 minut někdy od července, takže to můžu projít jestli se skok objevil už někdy dřív.
-
Wokna ve 3 ráno provádějí nějaké maintenance, update a podobné, podle mě to i syncuje čas a možná ledasco restartuje - podíval bych se jaký je čas v biosu, podle mě na to ta virtuálka může vidět, respektive nějaký bios a jeho čas určitě vidí tak jestli ten není nějak posunutý. A odhadem v těch 7 to syncuje čas s externími servery.
-
Jestli třeba v té virtuálce neběží čas Win rychleji a v ty tři ráno se to pokaždé nastaví správně.
-
Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.
S cim problem byt muze, je to, ze MS se dodneska tak uplne nenaucil co je to cas systemu (HW) a co je cas ktery ma zobrazovat uzivateli ...
-
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět.
Je ten rozdíl plus mínus pár vteřin pořád stejný? 2773 vteřin je tak divné číslo, že jediné reálné vysvětlení, které mne napadá, je že se to synchronizuje ze dvou různých zdrojů, a jeden z nich jde špatně. Nabízí se ty hardwarové hodiny, tj. ve vašem případě čas ve VMware.
Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.
Nikoli, systém si zjistí čas z hradwarových hodin akorát při startu, a pak už si udržuje čas sám, nanejvýš občas synchronizuje hardwarové hodiny se svým časem, aby v hardwarových hodinách po restartu bylo aspoň něco trochu správného. Systém si totiž umí udržovat čas daleko přesněji, než jak to dělají hardwarové hodiny.
Rozhodně to tak dělá Linux, a nedovedu si přestavit, že by to Windows dělaly jinak.
-
Tak je to ještě podivnější než jsem myslel. Dle zmiňovaných logů (běží tam věc, co periodicky každých 256,14 vteřiny udělá log. Neptejte se proč. Tak jsem projel log od července a vyfiltroval záznamy, kde dva po sobě jdoucí logy mají jiný rozdíl než 256,14 (plus pár vteřin rezerva). Našel jsem dvojí chování: Zhruba od července do půlky prosince to jelo většinu dnů bez problémů, jenom některé dny došlo ke skokům dopředu a zpět (třeba log v 1:43:19, další ve 2:36:24, další v 1:48:41, a pak několik třeba po deseti vteřinách. Jako kdyby čas skočil dopředu, pak se vrátil zpět a pak chvíli běžel pomalu a v řádu hodin se to srovná). Tohle se dělo 6.8., 11.8., 13.8., 14.8., 10.9., 26.9., 15.10., 22.10., 29.10., 12.11., 10.12. Jiné dny to jelo přesně log každých 256,14 vteřiny . (Kromě 26.10., kde vidím skok ve dvě o 3600s při změne času).
Od 12.12. Se chování změnilo. Každý den dojde ke dvěma skokům . V noci dopředu a ráno zpět. Počet vteřin o který to to skáče se každý den zmenšuje zhruba o vteřinu
12.12. 2794s
13.12. 2793s
14.12. 2792s
...
5.1. 2774s
6.1. 2773s
Skok dopředu je ve 3:20 +- 10 minut. Skok zpět bývá od pěti do osmi. (Proto jsme si toho všimli až teď, kdy někdo přišel do práce ještě před tím skokem zpět a všiml si to).
Uvedené výsledky stojí na tom, že onen log se generuje každých 256,14 vteřiny. Nicméně sedí s měřením oproti pool.ntp.org, které dnes změřilo taky skok 2773s.
Fakt mi to přijde jak kdyby se tam praly dva různé zdroje času a pak to dělá psí kusy.
-
Udelej paralelni cistou instalaci - zda bude mit stejne chovani.
Pokud ano, tak zapni kernel debugging a pripoj se tam debuggerem - uvidis spousty systemovych hlasek.
Apropo - do Event logu jste se dival?
-
Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.
Nikoli, systém si zjistí čas z hradwarových hodin akorát při startu, a pak už si udržuje čas sám, nanejvýš občas synchronizuje hardwarové hodiny se svým časem, aby v hardwarových hodinách po restartu bylo aspoň něco trochu správného. Systém si totiž umí udržovat čas daleko přesněji, než jak to dělají hardwarové hodiny.
Rozhodně to tak dělá Linux, a nedovedu si přestavit, že by to Windows dělaly jinak.
Aby jirsak, jako vzdyky, nemlel uplne zcesty. kazdej sytem ty tupce, dela to, ze cas od casu se snazi ty HW hodiny nastavit na cas toho systemu. Dela to tux, delaj to widle. A dela to pochopitelne vzdy, kdyz dojde na pokus o nejaky NTP a podobne. A presne jak sem psal, ve virtualni vm stroji se to nepovede. Widle o tom mlcej, tux to zaloguje.
Navic ty zjevne vubec netusis, ze existuje cosi jako vmware tools, coz je soubor driveru a systemovych servis, a mimo jine to zajistuje prave synchronizaci hodin. To je tak, kdyz je nekdo blbej jako Jirsak.
-
Zdravím,
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět. (Přesné časy skoků bych mohl dohledat z logů).
...
Pokud jste už vyčerpali ostatní možnosti, podíval bych se, zda nemůže jít o tzv. Secure Time Seeding:
https://learn.microsoft.com/cs-cz/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows
Na té stránce je i úprava registrů, kterou se to deaktivuje.
-
Status z dnešní noci (6.1. na 7.1.)
Došlo ke dvěma skokům o 2772 vteřin, z toho jeden byl pod pět minut. Je teda možné, že skoků je víc, jenom jsou tak krátké, že jsem si jich předtím nevšiml.
03:22:43, +00.0630457s
03:23:43, +00.0627538s
04:10:56, -2772.9436147s
03:25:43, +00.0026144s
03:26:43, +00.0025406s
03:50:43, -00.0001596s
03:51:43, -00.0001518s
03:52:43, +00.0063584s
04:39:56, -2772.9333399s
04:40:56, -2772.9331704s
...
05:00:57, -2772.9284102s
05:01:57, -2772.9283991s
04:16:44, +00.0004886s
04:17:44, +00.0002152s
04:18:44, +00.0002774s
Podíval jsem se do event vieweru (to mě předtím nenapadlo, resp. nejsem tak zkušený uživatel aby se mi v hlavě rozsvítilo koukni do event vieweru)
Tady je výcuc z dnešní noci. (od nejstaršího po nejnovější) pro Protokoly aplikací a služeb/Microsoft/Windows/Time-Service/Operational:
07.01.2026 3:24:47
W32time service has set the system time to 2026-01-07T02:24:47.837Z(UTC). Previous system time was 2026-01-07T03:11:00.782Z(UTC). System Tick Count: 2368186156
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
07.01.2026 3:24:47
W32time Service received notification to rediscover its time sources and/or resynchronize time. Reason Code:3 System Tick Count: 2368186156
Reason code description:
0 : An explicit time resynchronization request from an administrator
1 : Power state changes on this machine
2 : Changes to the network interface or to the network topology
3 : State changes within W32time that require time synchronization
The actions that follow this notifcation may impact fine-grained time synchronization accuracy.For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
07.01.2026 3:24:47
W32time service has set the system time to 2026-01-07T02:24:47.847Z(UTC). Previous system time was 2026-01-07T02:24:47.846Z(UTC). System Tick Count: 2368186156
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
07.01.2026 4:16:17
W32time service has set the system time to 2026-01-07T03:16:17.416Z(UTC). Previous system time was 2026-01-07T04:02:30.344Z(UTC). System Tick Count: 2371275718
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
07.01.2026 4:16:17
W32time Service received notification to rediscover its time sources and/or resynchronize time. Reason Code:3 System Tick Count: 2371275718
Reason code description:
0 : An explicit time resynchronization request from an administrator
1 : Power state changes on this machine
2 : Changes to the network interface or to the network topology
3 : State changes within W32time that require time synchronization
The actions that follow this notifcation may impact fine-grained time synchronization accuracy.For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
07.01.2026 4:16:17
W32time service has set the system time to 2026-01-07T03:16:17.426Z(UTC). Previous system time was 2026-01-07T03:16:17.426Z(UTC). System Tick Count: 2371275718
For more information, see https://go.microsoft.com/fwlink/?linkid=845961.
To vypadá, že v logu jsou jenom skoky zpět.
Udelej paralelni cistou instalaci - zda bude mit stejne chovani.
Pokud ano, tak zapni kernel debugging a pripoj se tam debuggerem - uvidis spousty systemovych hlasek.
To asi nechám až jako poslední možnost, navíc jak jsem říkal nemám fyzické železo ve správě, takže bych to mohl maximálně poradit správci
Pokud jste už vyčerpali ostatní možnosti, podíval bych se, zda nemůže jít o tzv. Secure Time Seeding:
https://learn.microsoft.com/cs-cz/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows
Na té stránce je i úprava registrů, kterou se to deaktivuje.
Podíval jsem se na konfiguraci a tato funkce je zapnuta (předpokládám že to je defaultní stav). Nicméně vzhledem k tomu, že v event viewru logu vidím jenom skoky zpět, tak mám pocit že spíš ta funkce vrací čas zpět, než že by způsobovala problémy. Ale nevím, zkusím to další noc vypnout a uvidím.
-
Tak předřečníci měli správné tušení, dělá to VMware tools
Našel jsem správu v Kernel-General (tato konkrétně je z 1.1.)
Systémový čas se změnil z 2026-01-01T02:18:12.278453600Z.
na 2026-01-01T03:04:30.211000000Z: 2777932 ms
Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Program Files\VMware\VMware Tools\vmtoolsd.exe' (PID 4296).
Čas RTC: 2026-01-01T04:04:30.211000000Z
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
a pak
Systémový čas se změnil z 2026-01-01T07:39:59.726921600Z.
na 2026-01-01T06:53:41.937212200Z: -2777789 ms
Důvod změny: An application or system component changed the time.
Proces: '\Device\HarddiskVolume3\Windows\System32\svchost.exe' (PID 1476).
Čas RTC: 2026-01-01T07:53:41.937212200Z
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
To samé v různé noční a ranní časy každý den o hodnotu, která se pravidelně snižuje.
třeba
1.1. 2777789 ms
2.1. 2777102 ms
3.1. 2776275 ms
4.1 2775442 ms
...
Teď už zbývá jenom zjistit proč to dělá.
S nadsázkou bych mohl říct, že dobrá správa je, při nějakém průměrném snížení skoku 0,8 vteřiny za den do deseti let problém zmizí sám. Špatná správa je, že možná to pak bude skákat dozadu a ntp to bude srovnávat dopředu. :D
-
"Synchronize guest time with host" je zapnuto nebo vypnuto?
-
Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/
-
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?
Dál bych zkoumal, zda nemám náhodou povolené dva (či více) mechanismy, aby mi konfigurovaly čas v guest-side OS.
Servisky dolaďující čas toto obvykle činí dolaďováním rychlosti běhu (="frekvence") softwarové časové základny. Pokud se začnou dvě různé zpětnovazební smyčky "pravidelně přetahovat o kormidlo", můžou být výsledky zajímavé.
Nebo jedna smyčka dolaďuje frekvenci, a druhý kousek softwaru dolaďuje periodicky skokem na chybný čas...
Doladění skokem je z hlediska best practices v oboru časomíry nešťastné řešení, ale při velkém rozdílu asi jediné správné.
Tzn. zatím by se hypoteticky mohlo jednat o soupeření mezi nativní MS serviskou w32time (která může brát buď NTP, nebo páchá zmíněný "Secure Time Seeding" ze SSL), vs. VMware Tools.
Kromě toho si guest OS při startu bere čas z emulovaného RTC, jak už tu správně psal Filip Jirsák.
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.
Dále, pokud by se stalo, že daný VM guest je v nějakých časových periodách držen hodně zkrátka co do přístupu ke strojovému času hostitelova CPU, takže mu softwarová časová základna běží pomaleji, než si třeba v lepších časech nakalibroval, velmi teoreticky by to taky mohlo vést k následným skokovým korekcím...
Neznám VMware. Třeba KVM+QEMU umí guestovi exportovat emulované fyzické hodiny "PHC", pro které je tuším guest-side virtio ovladač. Následně linuxový guest umí toto "autoritativní PHC" využít k doladění své softwarové časové základny, asi by podle toho uměl běžet i ntpd v guestově OS apod. Windows jsou v této oblasti za linuxovým světem vývojově pozadu, ale postupně to zaostávání dotahují. Nedávno přibyla podpora PTP (konkrétní profile), tuším i zárodek podpory pro HW timestamping v síťových kartách, nevím jak obecnější podpora PHC.
-
Na Windows (uvnitř QEMU+KVM) používám tohle, mohlo by pomoci. https://www.timesynctool.com/
1.) proti gustu žádný dišputát. Pokud Vám to funguje, klidně si poslužte...
2.) nemá specifickou podporu pro virtuální časoměrná zařízení hypervizoru QEMU+KVM (ani pro VMware)
3.) pokud to použijete, vypněte všechny ostatní způsoby dolaďování času ve VM guestovi = zastavte standardní MS servisku w32time, VMware tools, cokoli dalšího případně sahá na systémový čas
4.) ta věc je zcela banální SNTP klient, původně vyvinutý pro Win98. Tzn. patrně umí reálně méně, než standardní NTčkový w32time, a velmi pravděpodobně méně, než třeba Win32 build ntpd (nějaký binární build mají k dispozici Meinbergové, ale viděl jsem alternativní build i od někoho dalšího).
Ale ten Váš timesynctool bude také citelně méně složitý na konfiguraci, než zmíněné "seriózní" servisky.
-
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.
-
"Synchronize guest time with host" je zapnuto nebo vypnuto?
Těď jsem ji ve virtuálce vypnul. Uvidím zítra, jestli to pomůže
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
-
Pro doplnění, v jiné virtuálce se to děje taky. Fyzické železo je Dell Poweredge R350 a běží na něm ESXi.
-
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 (https://kb.meinbergglobal.com/kb/time_sync/time_synchronization_in_virtual_machines#vmware)]
[2 (https://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_basics#sudden_huge_time_steps)]
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í.)
-
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?
-
Tak bohužel, i když
C:\Program Files\VMware\VMware Tools>VMwareToolboxCmd.exe timesync status
DisabledStejně došlo ke skoku. Dneska ve 3:18 v noci skok 2772185ms a v 8:01 to w32tm srovnal zpět, skok -2772046 ms.
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: falseSysté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?
-
Dle dokumentace timesync disable vypne periodickou synchronizaci, ale ne změnu na základě eventů.
...
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.