El reloj de mi máquina virtual se desplaza bastante significativamente. Hay documentación por ahí sobre cómo lidiar con esto, pero nada parece estar funcionando muy bien.¿Cómo puedo resolver el reloj a la deriva de mi máquina virtual?
Alguien tiene alguna sugerencia, cosas que han funcionado bien para ellos, ...
Supuestamente actualizar regularmente a través de NTP no es una buena solución.
VMware tienen a really good PDF doc en este problema.
Básicamente, el anfitrión se mató a las garrapatas entregados a sus invitados como pueda. No ejecute NTP o cronometrado o basura como esa. Simplemente instale vmware-guestd y deje que el host elimine sus tics. Si aún pierde garrapatas, cualquier otra solución también tendrá mayor deriva.
Si puede, use un sistema operativo invitado que tenga una frecuencia de tick de baja frecuencia. Las versiones más nuevas de Linux vienen con tics de 1000Hz, pero solían ser 100Hz. Eso parece más fácil para el anfitrión para entregar. Por lo general, se necesita una reconstrucción del kernel para cambiar el valor de HZ.
Últimamente, muchos (¿la mayoría?) Núcleos de Linux distribuidos son en realidad "tickless", un concepto que no puedo explicar, pero este hilo puede: http://kerneltrap.org/node/6750 –
Esto fue cierto hace 10 años. Según la última KB: "VMware recomienda usar NTP en lugar de la sincronización periódica de VMware Tools", consulte http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 –
hilo en kerneltrap.org pero el enlace está muerto. – jesusduarte
¿No instalar las adiciones de máquina virtual (herramientas) sincronizar el reloj entre el huésped y el anfitrión OS?
Puede utilizar el cmd y
net time \\computer_name /set
para ajustar el reloj remotly (o en un script, por ejemplo)
Supuestamente la actualización periódica a través de NTP no es una buena solución
Esa es la solución que recomendaría, sin embargo. ¿Por qué no se considera bueno en tu ubicación?
Instale NTP si aún no lo tiene.
ntpdate será ajustado el reloj correctamente, entonces ntpd puede mantener el reloj de precisión.
El NTP pool project proporciona un gran número de servidores NTP para elegir.
Editar acaba de notar que dijiste que crees que NTP no es una buena solución, ¿por qué? Si estás preocupado por el efecto del cambio de reloj, NTP es el ideal, ya que ntpd no salta el reloj hacia delante o hacia atrás, sino que "desvía" el reloj acelerándolo ligeramente hacia arriba o hacia abajo hasta que vuelve a estar en línea con el tiempo correcto.
si ejecuto ntpdate -u actualizará el reloj ... sin embargo, después de 1 minuto ya estaré apagado por 5 segundos, por lo que tendría que ejecutar la actualización bastante a menudo. No estaba enterado, sin embargo, de la función de giro. todo lo que he usado es ntpdate -u que salta. – carrier
No hay una respuesta definitiva porque existen varios métodos, cada uno teniendo sus pros y sus contras. Lo que uno a elegir depende de sus tareas, la carga del servidor, sistema operativo, etc.
Leer vmware_timekeeping.pdf para la comprensión a fondo de la cuestión.
recetas rápidas para Linux se puede encontrar en una separada KB article
que tenía el mismo problema y lo resolvió por
Solo para agregar algunos datos acerca de por qué NTPD no es una buena solución. NTPD es un daemon que intenta compensar la deriva del reloj local; si el "reloj interno" se desplaza por X cantidad de segundos en un día, entonces en lugar de saltar adelante/atrás como un comando forzado como en "ntpdate", NTPD intenta agregar/eliminar algunos ciclos al reloj para que, a tiempo, normalmente En 15 minutos, el reloj funciona con la precisión suficiente y la compensación supera estos X números de segundos que el servidor gana/pierde en un día. Esto tiene la ventaja de que no verá ningún momento del día repetido, que es IMPRESCINDIBLE para los sistemas transaccionales.
Pero para poder hacer esto, NTPD requiere que el reloj local haga un trabajo razonablemente bueno, lo que normalmente significa que el reloj local no se separará más de 42 segundos al día (más o menos; seguro del número exacto). Esto normalmente es un problema en las máquinas virtuales, ya que el reloj está controlado por software, por lo que si el HOST tiene demasiada sobrecarga, puede ver que el reloj del CLIENTE se ejecutará más lentamente, y si no lo hace, el reloj podría funcionar también. rápido. El problema aquí para NTPD es que el reloj local no es confiable y no tiene una deriva constante en el tiempo; puede ser más o menos dependiendo de la sobrecarga del sistema HOST.
Así que en este caso es mejor instalar las herramientas de cliente como se ha sugerido, y sincronizar el reloj del cliente con el reloj del sistema (normalmente referido como el "reloj de pared")
Esto era cierto hace 10 años. Según el último KB: "VMware recomienda el uso de NTP en lugar de VMware herramientas de sincronización de tiempo periódico", véase http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 –
hora normal mejores prácticas para huéspedes Linux entre otras cosas dice: Ref: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
Recomendaciones NTP Nota: VMware recomienda utilizar NTP en lugar de las herramientas de VMware de sincronización de tiempo periódico. NTP es un estándar de la industria y garantiza un tiempo preciso para mantener a su invitado. Es posible que deba abrir el cortafuegos (UDP 123) para permitir el tráfico NTP.
Esta es una /etc/ntp.conf muestra:
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
Esta es una muestra (RedHat específica)/etc/ntp/paso-tickers:
0.vmware.pool.ntp.org
1.vmware.pool.ntp.org
La configuración directiva Tinker pánico 0 instruye a NTP a no darse por vencido si ve un gran salto en el tiempo. Esto es importante para hacer frente a grandes derivas de tiempo y también reanudar las máquinas virtuales desde su estado suspendido.
Nota: La directiva tinker panic 0 debe estar en la parte superior del archivo ntp.conf.
También es importante no utilizar el reloj local como una fuente de tiempo, a menudo denominado Reloj local indisciplinado.NTP tiene una tendencia a recurrir a esto con preferencia a los servidores remotos cuando hay una gran cantidad de deriva de tiempo.
Un ejemplo de una configuración de este tipo es:
server 127.127.1.0
fudge 127.127.1.0 stratum 10
comentario a cabo ambas líneas.
Después de hacer cambios en la configuración NTP, el daemon NTP debe ser reiniciado. Consulte la documentación del proveedor de su sistema operativo.
Este es un problema antiguo que nos estaba afectando recientemente. Lo que encontré fue que cualquiera de nuestras VM que estaban ejecutando herramientas vmware se vieron afectadas por el problema.
Más recientemente habíamos empezado a utilizar vm-open-herramientas y en aquellas de vm la opción no estaba definida. Desde-VM open-herramientas es totalmente compatible y recomendado por VMware se recomienda usar por encima de las herramientas de VMware: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2073803
Si-VM open-herramientas se encuentra en un repositorio que utiliza también es fácil de instalar a través de yum install o apt-get install etc.
¿Interesado en saber por qué ntp se supone que no es una buena idea? – cagcowboy
¿Qué sistema operativo está ejecutando su máquina virtual? –
sobre la solución NTP: Tengo que admitir que no puedo recordar en este momento la razón por la cual se desanimó NTP. Creo que quizás tiene que ver con la idea de usar diferentes métodos simultáneamente y cómo esto sería malo. – carrier