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?
-
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.
-
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é.
-
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.
-
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ášť.)
-
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).
-
nevím o tom, že by nějaká virtualizační technologie udržovala systémové hodiny pro každého hosta zvlášť.
VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.
-
VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.
Díky, nevěděl jsem, že už tam tato možnost je. (Teď se ukáže, že „už“ je 20 let…)
Škoda, že tu není možnost jenom dát komentáři palec nahoru, bez dalšího okecávání.
-
Povedlo se mi reprodukovat skoky, k posunu dojde i když ručně vypnu a zapnu servicu vmtoolsd. Po naběhnutí okamžite skok.
Z debug logu
...
[2026-01-08T17:10:29.805Z] [ debug] [vmtoolsd] [13096] Setting option 'synctime.period' to '0'.
[2026-01-08T17:10:29.805Z] [ debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.enable' to '1'.
[2026-01-08T17:10:29.805Z] [ debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync' to '0'.
[2026-01-08T17:10:29.805Z] [ debug] [vmtoolsd] [13096] Setting option 'time.synchronize.guest.resync.timeout' to '0'.
[2026-01-08T17:10:29.805Z] [ debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup.backward' to '0'.
[2026-01-08T17:10:29.807Z] [ debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.startup' to '1'.
[2026-01-08T17:56:41.436Z] [ debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterPowerOn' to '1'.
[2026-01-08T17:56:41.436Z] [ debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforePowerOff' to '1'.
[2026-01-08T17:56:41.436Z] [ debug] [vmtoolsd] [13096] Setting option 'toolScripts.afterResume' to '1'.
[2026-01-08T17:56:41.436Z] [ debug] [vmtoolsd] [13096] Setting option 'toolScripts.beforeSuspend' to '1'.
[2026-01-08T17:56:41.436Z] [ debug] [vmtoolsd] [13096] Setting option 'time.synchronize.tools.slewCorrection' to '1'.
...
Takže s největší pravděpodobností je na ESXi špatně nastavený systémový čas a v noci dojde k nějakému eventu, který vynutí resync i když je "vypnutý". Dle dokumentace
Virtual machine occasionally synchronizes time with the host even if you do not turn on periodic time synchronization. To completely disable time synchronization, you must set some properties in the virtual machine configuration file.
Power off the virtual machine.
Open the configuration (.vmx) file of the virtual machine in a text editor.
Add lines for the time synchronization properties and set the properties to FALSE.
tools.syncTime = "FALSE"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"
Save and close the file.
Při restartu vmtoolshd procne ten time.synchronize.tools.startup. V noci procne třeba něco jinýho.
Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.
-
Takže mi z toho vychází, že je špatně buď systémový čas v ESXi, nebo zmiňovaný offset (minimálně) pro tuto virtuálku. Čekám až se mi ozve admin. Skoro bych tipnul, že se u nás na firmě zprovoznil server, nastavil se čas a pak na to roky nikdo nešáhnul, ntp nebylo zapnuto, no a čas vesele driftuje o tu 0.8 vteřinu denně (což mi ale přijde docela dost). Ale třeba se pletu.
Vypadá to na neudržovaný čas na hostiteli.
Přesnost krystalu bez teplotní kompenzace je 10-50ppm, drift 0.8s/den je ještě dobrý výsledek.
-
VMware potřebuje čas z hostitele při událostech boot/suspend/resume/snapshot, když musí posunout virtuální RTC a TSC o čas, kdy host spal a virtualizovaný OS o tom neví.
HPET VMware emulovat neumí.
-
Tak potvrzeno, v ESXi byl o těch 46 minut špatný (neudržovaný čas). No a když denní drift je asi -0,8 vteřiny, server jsme pořizovali zhruba před 2,5 lety, tak to krásně vychází, že se od té doby posunul zhruba o 15 minut dozadu. No a jelikož při pořízení byl letní čas, tak proti aktuálnímu času je to těch 45 minut dopředu.
<Facepalm>
Mohlo mě to napadnout dřív, než jsem tady začal plašit; ale diskuze byla myslím alespoň pro mě docela poučná.
Jako anekdotu na závěr můžu zmínit, že virtuálku jsme používali interně ve firmě na vyčítání události z Jablotroní sběrnice (příchody / odchody lidí dle pípnutí karty). Takže lidi, co měli to štěstí a přišli před tím, než si virtuálka ráno chytla správný čas, měli občas zvědavé dotazy, proč mají v systému příchod v 7:46 kyž si pípli v 7:00 ;D
-
Kromě 26.10., kde vidím skok ve dvě o 3600s při změne času
26.10.2025 se menil letny cas
-
Gratuluji k vyřešení, a děkuji za zajímavý dotaz.
Přestože teď máte hypervizor už zasynchronizovaný, doporučuji ponechat guestům aktivní pouze jeden způsob synchronizace: w32time, nebo VMware Tools, nebo nějaký další. Pokud necháte aktivní dva nebo více způsobů synchronizace uvnitř jednotlivého guesta, zvyšuje se riziko "zvláštních efektů" (houpání zpětnovazební smyčky dolaďování frekvence apod.)
Mimochodem, ohledně přechodů zimní/letní čas... UNIX jede interně UTC, Windows podle mého taky. Časová zóna a střídání zimního/letního času je za běhu záležitostí prezentace v uživatelském rozhraní (s podporou systému).
Doporučil bych nastavit vindózům ve VM, ať si čas do emulovaného RTC ukládají v UTC (především bez střídání letního a zimního času). Pak by Vám měly odpadnout skokové změny, pokud guest VM změnu času "prospal" ve vypnutém stavu.
Zdá se, že emulovaný RTC (jak ho vidí guest VM) umí uložit aktuální čas guesta - ovšem neukládá ho jako absolutní čas, ale jako offset oproti času hostitele=hypervizoru. Emulovaný RTC proto při vypnutém guestovi nedriftuje, "tiká pořád přesně". Ofset emulovaného RTC lze snad také nastavit explicitně, per guest...
Ohledně chování emulovaného RTC ve VMware najde Google jenom letité PDFko (https://www.vmware.com/docs/vmware_timekeeping) (kapitola "Virtual CMOS RTC" na str.7). Meinbergové mluví také o VMware knowledge-base záznamu na téma timekeeping - netuším, jestli je to dnes k dispozici jenom po přihlášení / v rámci placeného supportu nebo jak.
-
K tomu bych měl dotaz, počítá si windows nějak "ticky času" že ví že běžel třeba x dní čistého času (po nějakých třeba minutových checkpointech) a pak se nastřádaný drift času při posunu systémového data v hypervizoru /biosu/nastavení času v guestovi nějak projeví?
-
K tomu bych měl dotaz, počítá si windows nějak "ticky času" že ví že běžel třeba x dní čistého času (po nějakých třeba minutových checkpointech) a pak se nastřádaný drift času při posunu systémového data v hypervizoru /biosu/nastavení času v guestovi nějak projeví?
Nerozumím otázce :-( Zkuste to pomaleji, pro mě pomalejšího...
Podrobnosti:
Zjistit uptime ve Windows lze, nejsnáz asi v Task Manageru = správci úloh (Ctrl+Shift+Esc), menu vlevo Výkon -> Procesor. V levém dolním rohu je číslo ve formátu dny:hodiny:minuty:sekundy od startu.
Datum a čas posledního startu se dá zjistit z příkazového řádku takto:
systeminfo | find "System Boot Time"
Windowsy při startu natáhnou momentální lidský čas z RTC, a při vypnutí aktuální čas do RTC uloží. RTC je maličký šváb nebo blok v čipsetu někde na motherboardu, zálohovaný knoflíkovou baterkou. Má krystal 32768 Hz, děličku 1/2^15 a pár registrů mapovaných do IO space hostitelského procesoru.
Mezi startem a vypnutím jede čas softwarově. HW RTC kdesi na motherboardu sice za běhu OS běží dál, ale nebere se na něj ohled. OS si jede "v softwaru" svoji vlastní runtime časovou základnu. Tato softwarová časová základna používá jeden z několika HW čítačů/časovačů architektury PC, kterým se nechá pravidelně budit pomocí IRQ. V DOSu tradičně byla perioda časovače asi 54.9 ms (18.2 Hz), pod Windows tradičně 15.6 ms. Relativně moderním trendem je, že se systémová časová základna naschvál budit nenechá, aby šetřila napájení - a vzbudí se jenom když je příležitost, a uběhlý čas počítá podle hardwarového TSC, což je primitivní 64b registr CPU, který počítá tiky "furt dopředu". Klíčová slova v linuxu jsou tickless / dynticks.
Softwarové časové základny se lze kdykoli zeptat "kolik je hodin", a ona odpoví s rozlišením buď na milisekundu, nebo tuším 100 ns (WinAPI funkce GetSystemTime() a GetSystemTimeAsFileTime()). V zásadě si interně drží údaj, kolik bylo hodin, když byl naposledy vyvolán její interrupt časomíry, a jaký byl tehdy stav TSC, takže kdykoli se nějaký ostatní software zeptá, časová základna si prostě dopočítá, kolik zrovna je. Dotaz na TSC je softwarově "levný", je na to instrukce CPU.
Systémovou časovou základnu lze také požádat "vzbuď mě za 11m:23s" nebo "vzbuď mě v 03:34:25". V tom případě si i tickless kernel "nastaví budíka v hardwaru" a v nastaveném čase obdrží interrupt - v rámci jeho obsluhy nastaví čekajícímu procesu "runnable" flag a pošťouchne scheduler k činnosti...
Systémová softwarová časová základna má ponětí, jaký časový úsek odpovídá jednomu tiku periodického timeru (postaru) resp. jednomu tiku TSC (ponovu/tickless). Pokud zavěsíte systémovou časovou základnu na upstream NTP, tak si tuto představu či koeficient průběžně aktualizuje, případně dokáže ovlivňovat frekvenci tikání periodického timeru (postaru). Vlastní systémová časová základna žije v kernelu (odehrává se částečně v kontextu IRQ). Závěs na NTP zajišťuje user-space prográmek (serviska) - tato sleduje odchylku lokální časové základny od upstream NTP, velkou odchylku doladí jednorázově skokem, následně malé odchylky dolaďuje jemnými změnami "rychlosti běhu lokální systémové časové základny". Pro toto dolaďování parametrů běhu poskytuje časová základna WinAPI funkci SetSystemTimeAdjustment() - obdoba linuxové adjtimex().
Systémová časová základna používá hodinový takt a HW čítače/časovače, které jsou živé při běhu počítače (ve vypnutém stavu nikoli). Lokální referencí těchto různých provozních taktů a čítačů je v konečné instanci jeden konkrétní krystal na motherboardu, od kterého jsou sychronními děličkami a PLL syntezátory odvozené hodiny pro všechny sběrnice / procesor / čipset. (Sem tam nějaká periferie má šutr svůj vlastní, třeba ethernetové čipy.) Tenhle krystal není nijak zvlášť přesný a stabilní - řekněme něco jako 10^-5 až 10^-6. Proto si softwarová časová základna může nastavit dělící poměr používaného HW čítače/časovače (pokud to lze), nebo spíš jeho mírnou odchylku post-kompenzuje softwarově při přepočtech na lidský čas.
Časová základna moderních operačních systémů, a také například NTP, běží interně v UTC. Což je stupnice, která občas vloží přestupnou sekundu (nebo teoreticky taky vypustí, což se ale nikdy nestalo). Existují příbuzené stupnice, které tikají stejně rychle, ale přestupné sekundy nevyužívají, a tedy mají oproti UTC pevný offset: zmínil bych GPS time a ještě třeba TAI (kterou znám z protokolu IEEE1588=PTP).
UTC nevyužívá přechody zimní/letní čas.
Lokální časové zóny a přechody zimní/letní čas jsou záležitostí "prezentace v uživatelském rozhraní". Operační systém nabízí připravené funkce ke konverzím časové značky mezi zónami, ale systémová časová základna toto v podstatě neřeší - tiká si prostě svoje UTC.
No a ve virtualizačním prostředí lze nastavit, aby emulovaný guest-side HW RTC tiše ignoroval nastavení času při vypnutí OS ve VM guestovi, a aby namísto toho při každém zapnutí guesta emulovaný RTC převzal čas z časové základny hostitelského hypervizoru. Hypervizor může být zavěšený na NTP apod. Díky tomu má VM guest po každém zapnutí přesný čas.
Věc má nuanci. Aneb čerstvá příhoda z natáčení, aktuální Proxmox vs. aktuální Windowsy:
UNIX a Linux tradičně ukládá čas do RTC v zóně UTC.
Naopak Windows Server dodnes by default předpokládá, že RTC jede v lokální časové zóně! Je to zjevně dědictví desktopových windows a DOSu a světa IBM PC, kdy se RTC provozoval tradičně v lokální časové zóně (protože dávný OS nevěděl, že je něco jiného než lokální čas.)
Což vede k různým legracím pokud střídání času proběhne ve chvíli, kdy počítač neběží. Nebo ho obnovíte ze zálohy, která byla pořízena v opačném stavu letního/zimního času. Nebo počítač startuje z disku v read-only režimu. Windows totiž provedou přechod na letní čas ve chvíli, kdy ho "zažijí v zapnutém stavu", nebo nastartují v období letního času, aniž by měly na disku záznam, že provedly poslední proběhlý přechod.
Takže Windows Server předpokládá a používá RTC v lokální časové zóně, včetně přechodů léto/zima.
Proxmox o tom ví, pročež je by default nastavený, aby emulovaný RTC startoval s časem v lokální časové zóně.
Problém nastane ve chvíli, kdy virtuál s instancí Windows Serveru spouštíte jenom občas, podle potřeby. Takže se stane, že během přechodu zimní/letní čas je virtuál vypnutý. Při dalším startu mu Proxmox podá RTC už po přechodu se správným lokálním časem... a Windowsy ve VM guestovi si přechod provedou *znovu* - takže běží s časem posunutým o hodinu vedle :-)
Jak tomuto jevu zabránit? Osobně bych navrhoval, držet se UNIXové konvence: RTC jede v UTC.
Kupodivu není úplně snadné, přemluvit aktuální Windows Server, aby si RTC provozoval v UTC! (Nešlo to kdysi během instalace jedním kliknutím?) Je potřeba sáhnout do powershellu:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
A v Proxmoxu ve vlastnostech VM je také třeba nastavit, že emulovaný RTC uvnitř guest VM jede v UTC.
Zvolte dotyčný guest VM -> Options -> Use local time for RTC: *No*
-
K tomu bych měl dotaz, počítá si windows nějak "ticky času" že ví že běžel třeba x dní čistého času (po nějakých třeba minutových checkpointech) a pak se nastřádaný drift času při posunu systémového data v hypervizoru /biosu/nastavení času v guestovi nějak projeví?
Pokud budu dotaz chápat v obecném slova smyslu cca takto:
Mějme časovou základnu, která je v závěsu na nějaké upstream referenci. Tento závěs zajišťuje průběžnou úpravu kalibrace = upravuje nějaký korekční parametr "lokálního oscilátoru", aby tento běžel "v průměru furt rovně, nejlépe s co nejmenším jitterem/wanderem".
Ten korekční parametr může být ladící napětí krystalového oscilátoru (VCXO), nebo třeba nějaký násobič v přesném syntezátoru (např. syntík v PHC síťovky i210 lze ladit s rozlišením tuším asi 10^-8), nebo třeba u softwarové časové základny windows lze upravovat časový úsek dwTimeAdjustment uběhlý za shůry danou periodu lpTimeIncrement. Kalibrační parametr má rozlišení 100 ns. Pokud jsou dwTimeAdjustmeint a lpTimeIncrement oba shodně 156250, běží hodiny s nulovou korekcí. Všimněte si, že rozlišení této korekce je cca 10^-5, což je poměrně hrubé rozlišení.
Ať už je mechanismus korekce jakýkoli, může jeho zpětná vazba fungovat pouze ve chvíli, kdy je k dispozici upstream reference (zdroj přesného času). Pokud zmizí upstream reference, lokální časová základna bude volnoběžet buď s poslední hodnotou kalibračního parametru, nebo třeba s průměrem za poslední den, nebo se může pokusit, predikovat další vývoj/trend kalibrace... Potíž je, že kalibrace prostého krystalu má vždy velikou náhodnou složku, zejména v závislosti na teplotě. Veliká náhodná složka, pod Windows mizerné rozlišení kalibračního parametru... a pak se v tom snažte predikovat nějaký trend :-)
Stabilitu lokální časové základny (i po zohlednění kalibrace včetně případné predikce) lze hodnotit pouze pokud je k dispozici přesná a autoritativní externí reference :-) Pokud v reálné situaci volnoběžíte, protože Vám upstream reference umřela, tak jaksi nemáte divergující odchylku podle čeho hodnotit... Lze to jedině v nějakém laboratorním testu, kde pro potřeby měření referenci samzřejmě zachováte v provozu, ale seberete zdroj času testvanému zařízení s hodnoceným oscilátorem...