Por qué NTP sigue ejecutándose dentro de las máquinas virtuales pese a los agentes invitados y los relojes paravirtualizados

Qué es

La percepción de la hora dentro de una VM depende de más de un mecanismo. En KVM, la documentación de timekeeping del kernel describe kvmclock (kvmclock/kvm-clock) como una fuente de reloj (clocksource) paravirtualizada que el kernel invitado puede usar en lugar de emular por software un reloj de hardware, lo que reduce la deriva y la sobrecarga que provocan la interceptación y la emulación del hardware de temporización. Por separado, QEMU ofrece el QEMU Guest Agent (qemu-ga), un demonio instalado dentro del invitado que permite al host enviarle comandos a través de un canal virtio-serial. Es un canal de gestión, no una fuente de reloj, aunque puede ajustar una vez la hora del invitado cuando se le solicita (virsh domtime <domain> --sync, que lee la hora del RTC del invitado). Hyper-V incluye sus propios servicios de integración, entre ellos un servicio de sincronización horaria (vmictimesync) que sincroniza el reloj del invitado con el del host.

Por qué importa

Ninguno de estos mecanismos sustituye a un cliente de sincronización horaria (chronyd, systemd-timesyncd o el servicio Windows Time) ejecutándose dentro del invitado:

• kvmclock mejora la calidad y la estabilidad de la fuente de reloj disponible para el kernel invitado; no sincroniza el invitado con la hora real y aun así puede derivar, en particular tras migraciones del host, suspensión/reanudación del host o una fuerte contención de CPU en el host que retrase el momento en que la CPU virtual del invitado se ejecuta realmente.
• El agente invitado de QEMU puede ajustar el reloj de golpe una sola vez cuando se le indica (por ejemplo, tras una reanudación), pero no disciplina el reloj de forma continua.
• El componente de sincronización horaria de Hyper-V sigue el reloj del host, de modo que el invitado solo es tan preciso como el host; el propio host sigue necesitando una buena fuente de hora, y el invitado sigue beneficiándose de su propio servicio de hora (Windows Time, chronyd o systemd-timesyncd).

Cómo aplicarlo

• Mantén un cliente NTP/chrony (o Windows Time) activo y bien configurado dentro de cada invitado, sea cual sea el hipervisor o las herramientas de invitado instaladas.
• Tras migraciones del host, restauraciones de snapshots o la reanudación de una VM pausada o suspendida, espera un salto en la hora del invitado hasta que el cliente interno la corrija; comprueba el estado del servicio (chronyc tracking, w32tm /query /status) después de esos eventos en lugar de dar por supuesta la continuidad.
• Confirma qué clocksource usa realmente un invitado Linux: cat /sys/devices/system/clocksource/clocksource0/current_clocksource (normalmente kvm-clock en invitados KVM; los kernels invitados más recientes pueden preferir tsc cuando el host expone un TSC invariante estable). cat /sys/devices/system/clocksource/clocksource0/available_clocksource muestra las alternativas.
• Trata las indicaciones de hora proporcionadas por el host (el servicio de integración de sincronización horaria de Hyper-V, el equivalente de VMware) como una capa de corrección aproximada junto al servicio de hora propio del invitado, y consulta las recomendaciones del fabricante del hipervisor para roles especiales, como los controladores de dominio virtualizados, donde ambas fuentes pueden entrar en conflicto.

Trampas

• Desactivar el cliente NTP del invitado porque «el hipervisor se encarga de la hora» y ver después fallos de validación de certificados, de Kerberos o de correlación de logs tras una migración o una reanudación.
• Suponer que kvmclock por sí solo mantiene exacta la hora del sistema (wall-clock time); es una propiedad de la fuente de reloj, no un protocolo de sincronización.