¿Necesito ejecutar un servidor NTP en cada VM?

¿No podrían los invitados de alguna manera heredar la hora del sistema del host?

Parece inútil ejecutar el mismo demonio para obtener los mismos resultados en la misma máquina varias veces, pero no encontré nada relacionado con el tiempo al leer artículos de KVM o Xen. Tengo entendido que el invitado obtiene el tiempo de host en el arranque, pero que luego puede separarse. Es eso correcto ?

Esto es correcto. Cabe señalar que el tiempo no solo "puede" derivarse, sino que se alejará debido al hecho de que los intervalos entre las interrupciones del temporizador (en las que a menudo se basa el cronometraje en el sistema operativo) se estiran y comprimen como el hipervisor lo considere adecuado.

Una solución alternativa comúnmente utilizada en la mayoría de las plataformas de virtualización (servicios de integración Hyper-V, herramientas VMWare) es ejecutar un demonio en el invitado que sincroniza periódicamente los relojes con el host VM. Como señaló Hauke ​​en un comentario a su pregunta, KVM también proporciona un reloj paravirtualizado que necesitaría el controlador respectivo cargado en el sistema operativo invitado para funcionar.

Cronometraje en máquinas virtuales VMWare (vmware.com)
Sincronización de reloj de invitados KVM (s19n.net)

En un mundo perfecto, sus invitados VM mantendrían el tiempo perfecto, o al menos tan perfecto como el host proporciona. Lamentablemente no vivimos en un mundo perfecto.

Según mi experiencia con prácticamente todos los hipervisores conocidos por el hombre, siempre ejecuto un cliente NTP en máquinas virtuales, sin excepción. Mi configuración habitual es ntpd con la opción -g, o ntpdate que comienza justo antes para los sistemas antiguos, para acelerar el reloj (que puede estar muy fuera de sincronización en el arranque del sistema).

KVM tiene una configuración casi perfecta, con su reloj en tiempo real paravirtualizado ; los invitados con el controlador apropiado (todos los Linux recientes, al menos) mantendrán el tiempo y el host. Pero aún así las cosas salen mal aquí: por ejemplo, el host puede no estar ejecutando NTP, el host puede tener una zona horaria incorrecta, el reloj del host puede estar simplemente mal, etc.

VMware e Hyper-V caen en el medio. Cada uno tiene una herramienta destinada a ejecutarse en el invitado que sincroniza el reloj con el host periódicamente, pero de nuevo, esto es vulnerable a cualquier problema existente con el reloj del host.

Los invitados en mi servidor Hyper-V de prueba también exhibieron un comportamiento extraño: incluso con los servicios de integración, el reloj del invitado se desplazaría más rápido que 500 ppm, evitando que el ntpd funcione ( considera que el reloj está loco si se mueve más rápido que esto ). Tuve que cambiar estos invitados a crony , lo que permite que este valor se ajuste.

Xen es lo peor a este respecto; no tiene absolutamente ninguna sincronización y es casi obligatorio ejecutar NTP en los invitados. (Me han dicho que las versiones muy recientes de Xen tienen algún tipo de sincronización pero aún no he trabajado personalmente con ella).

Las cosas empeoran si el hipervisor host no está bajo su control, como una nube pública. Estás a merced del proveedor con respecto al reloj del host, y si no son diligentes para mantenerlo sincronizado, pierdes.

Con todo eso, ejecutar clientes NTP en sus máquinas virtuales es bastante necesario si necesita incluso un reloj semi-preciso. NB: si ejecuta máquinas virtuales de Windows, obtenga un cliente NTP de terceros que ajuste el reloj continuamente; La pobre excusa para un cliente que viene con Windows solo ajusta el reloj una vez por semana , lo cual es completamente ridículo.

Recomendaría usar NTP porque es bien conocido y existe desde hace mucho tiempo. Ajustar el reloj no es trivial. NTP ha resuelto este problema.

La línea oficial de VMware es usar un mecanismo, con NTP preferido porque es más fino y toma medidas más pequeñas para ajustar el tiempo. La solución interna de VMware da pasos más grandes. Cuando corres ambos, podrían pelear entre ellos. Con la solución interna de VMware dando un gran paso y luego NTP ajustándola y retirándola un poco.

En la práctica, sin embargo, corremos ambos al mismo tiempo y todavía no he visto ningún problema.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status