avvio del kernel nei registri: set_rtc_mmss non può aggiornare da 0 a 58

Ho visto un gruppo di questi messaggi di registro

Jan 3 00: 58: 57 foo kernel: set_rtc_mmss: can't update from 0 to 58 

Si verificano su CentOS 6.4 VM in esecuzione su VMware. Capisco che sia qualcosa a che fare con l'orologio hardware non essere impostato correttamente sul OS ospite. Ho trovato questo command che imposta l'orologio hardware all'ora corrente del sistema:

 sudo hwclock --systohc 

È questa l'impostazione corretta per una macchina virtuale? Inoltre, where può essere impostato così è persistente? Nei parametri di avvio del kernel? Vorrei che i VM forniti di recente non abbiano questo problema.

AGGIORNAMENTO 1

Come richiesto:

 me@foo:~> ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 43 64 377 0.000 0.000 0.000 +dtc-nist01.ntp. .ACTS. 1 u 174 1024 377 3.311 -8.554 0.497 *nist1-nj.ustimi .ACTS. 1 u 205 1024 377 6.737 3.775 0.433 +nist1-pa.ustimi .ACTS. 1 u 55 1024 377 8.610 4.688 0.337 

Vedo vmwaretools è scaduto su questo VM. Forse il module fantoccio che ho per gestire l'installazione di vmwaretools non l'ha installata correttamente. Ti guarderò e tornerò da te.

AGGIORNAMENTO 2

Sì, gli strumenti vmware sono installati e all'ultima versione.

 me@foo:~> ps aux | grep vmtools root 56021 0.0 0.1 59508 4156 ? S Jan09 3:29 /usr/sbin/vmtoolsd 

UPDATE 3

Ho provato l'triggerszione della "sincronizzazione del tempo ospiti con host" sul VM:

 me@foo:~> vmware-toolbox-cmd timesync status Disabled me@foo:~> vmware-toolbox-cmd timesync enable me@foo:~> vmware-toolbox-cmd timesync status Enabled 

ma sto ancora ricevendo questi messaggi. Infatti, date e hwclock --show sono alcuni minuti di distanza adesso, mentre erano abbastanza stretti.

In passato, i vecchi SLM 9 VM hanno beneficiato delle impostazioni nell'articolo VMware le migliori pratiche per gli utenti di Linux , ma afferma che gli ospiti CentOS / RHEL 6 non necessitano di altri parametri di kernel aggiuntivi.

UPDATE 4

L'aggiornamento a CentOS 6.5 non ha aiutato. Il kernel è:

 Linux foo 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux 

  • Qual è il modo corretto per risolvere un cluster HA?
  • Migrazione di VM da Virtual a Server fisico
  • VMXNET3 nic perde la capacità di aggiornare la tabella ARP dopo le ore N
  • Software RAID sotto ESXi datastore
  • Quali sono le mie opzioni di automazione con VMWare ESXi 3?
  • Dove posso imparare i fondamenti su ipervisori nel context di altre soluzioni di virtualizzazione hardware?
  • ESXi - console seriale come console predefinita
  • Esegui una macchina virtuale su un server Linux + le funzioni standard di Linux
  • 3 Solutions collect form web for “avvio del kernel nei registri: set_rtc_mmss non può aggiornare da 0 a 58”

    VMWare ha alcuni suggerimenti nella base di conoscenze su come configurare il client ntp nel tuo os ospite. La prima cosa è assicurarsi che la timesync di vmware-toolbox sia disabilitata, in quanto volete solo che ntp aggiorna l'ora.

    Dalle migliori pratiche dell'orologio per gli ospiti di Linux :

    Questo è il loro esempio /etc/ntp.conf :

     tinker panic 0 restrict 127.0.0.1 restrict default kod nomodify notrap server 0.vmware.pool.ntp.org server 1.vmware.pool.ntp.org server 2.vmware.pool.ntp.org driftfile /var/lib/ntp/drift 

    La prima row ( tinker panic 0 ) consente grandi salti di tempo. (ad esempio lo stato del sistema è stato salvato / ripristinato)

    Un'alternativa sarebbe disabilitare ntp nel tuo ospite e abilitare la sincronizzazione del tempo di vmware-tools.

    Stai eseguendo l'ultima versione del kernel per CentOS 6.4? Vorrei provare l'avvio con clocksource = acpi_pm. Inoltre, farei ntpdate -u tick.usno.navy.mil && hwclock –systohc e lasciate che le cose siedano. Se le cose continuano, quindi aggiungere anche divisore = 10.

    Onestamente, ho il sospetto che il problema è in parte con il codice del tuo particolare kernel per impostare e leggere l'orologio in tempo reale – questo è ciò che ti arriva il messaggio di errore. L'altra parte è dovuta agli interrupt di tempo virtuali che non vengono consegnati regolarmente abbastanza o il gestore di interrupt del timer non scalare correttamente il tempo del kernel – e questo è ciò che ti rende la deriva dell'orologio.

    Forzare il ntp per essere più aggressivo è solo una maniglia per il problema, purtroppo.

    È disponibile un nuovo kernel? Quella potrebbe essere la tua scommessa più sicura. In bocca al lupo.

    Sulla base di tutto il resto che ho letto, sembra che questi avvertimenti siano benigni, soprattutto se la date tuoi server è soddisfacente. Un po 'fastidioso però.

    Lascio che questo tidbit da ntp.org mi metta a proprio agio:

    Per http://www.ntp.org/ntpfaq/NTP-s-trbl-spec.htm#Q-LINUX-SET-RTC-MMSS :

    8.3.4.1.1. Cosa significa set_rtc_mmss: non può aggiornare da 54 a 5 significa?

    La function set_rtc_mmss () aggiorna minuti e secondi dell'orologio CMOS dall'orologio di sistema. Non aggiorna l'ora o la data per evitare problemi con i timezones. [1] Il messaggio visualizzato è stato aggiunto per rendere agli utenti e agli implementatori consapevoli del problema che non tutti gli aggiornamenti di tempo avranno successo.

    Immagina che l'orario del sistema sia 17:56:23 mentre l'orologio CMOS è già alle 18:03:45. L'aggiornamento di pochi minuti e secondi avrebbe fissato l'orologio hardware a 18:56:23, un valore errato. La soluzione per questo problema è di attendere qualche minuto o di installare una patch del kernel che risolve il problema. Normalmente un orario errato nell'orologio hardware non verrà visualizzato fino al riavvio o forse dopo che APM rallenta il sistema.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.