El problema

Question 1

El problema

Tengo el mismo problema y no he encontrado una buena solución. Esto es lo que encontré:

El problema es que después de la reanudación, los tiempos del reloj del sistema y del hardware del invitado son diferentes:

root@guest:~# date; hwclock
Sat Oct 11 13:09:38 UTC 2014
Sat Oct 11 13:10:42 2014  -0.454380 seconds

Sobre el anfitrión, coinciden:

root@four:~# date; hwclock
Sat Oct 11 13:11:35 UTC 2014
Sat Oct 11 13:11:36 2014  -1.000372 seconds

La solución sería ejecutar hwclock --hctosysel invitado después de que se haya reanudado. Sin embargo, no he encontrado una manera de hacer esto solo con cambios en el sistema invitado, ya que el invitado no se da cuenta de que está suspendido y reanudado.

Agente invitado de QEmu

Existe la posibilidad de ejecutar un software llamadoAgente invitado de QEmuen el invitado y notificar desde el host para actualizar el reloj del sistema invitado desde el reloj del hardware invitado. Sin embargo, la página menciona que elEl agente invitado hace que el anfitrión y el invitado sean vulnerables a los ataques.entre sí debido a problemas con un analizador JSON (al menos creo que el código afectado también se ejecuta en el host, no estoy seguro de eso). De todos modos, aquí se explica cómo configurarlo:

Configure un canal serie virtio para el agente como se menciona en lalibvirtwiki(ver tambiéndocumentación del formato de dominio libvirt).
Una vez que el canal serie esté disponible, instale e inicie QEmu Guest Agent en el invitado. (Debian:. apt-get install --no-install-recommends qemu-guest-agent)
Active el reloj compensado suspendiendo, esperando y reanudando. Luego ejecute el siguiente comando en el host para corregirlo: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'La página wiki que usa virsh qemu-agent-commandessin apoyo, pero no he encontrado ningún otro comando que haga el trabajo.

Encontré dos discusiones sobre la automatización dentro de libvirt de la llamada al guest-set-timecurrículum desde la suspensión:

http://thread.gmane.org/gmane.comp.emulators.libvirt/92431(Febrero 2014)
http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051(septiembre de 2014)

Sin embargo, hasta donde pude ver, todavía no se ha implementado nada.

Encontré información sobre cómo enviar comandos al agente invitado enwiki de stoney-cloud.org.

También he intentado configurar tickpolicy="catchup"en elconfiguración del temporizador libvirtpero esto no resolvió el problema.

NTP

Una alternativa al uso del agente sería utilizar un demonio ntp o llamar a ntpdate periódicamente desde un trabajo cron. No recomendaría esto último, ya que puede hacer que el tiempo retroceda, lo que puede confundir a los programas (por ejemplo, elEl servidor IMAP de Dovecot no intenta manejar el tiempo hacia atrásy puede rescindir).

Probé los siguientes demonios ntp:

abrirntpd: Corrige el tiempo muy lentamente a un ritmo de aproximadamente 2 segundos cada 60 minutos en mi prueba. El desfase de tiempo fue de 120 segundos. También,abrirntpdarroja un error si el desplazamiento de tiempo es demasiado grande y, en mi prueba, no corrige por completo el tiempo en ese caso. Ventajas de openntpd: Puede ejecutarse como usuario normal en chroot.
crono: Corrige un desfase de tiempo de 120 segundos en 30 minutos en mi prueba. chrony se puede configurar para ejecutarse como usuario normal. El soporte chroot no está implementado. El intervalo de sondeo del servidor NTP se puede configurar para cada servidor NTP.
systemd-timesyncd: Corrige un desplazamiento de tiempo de 120 segundos en 30 segundos en mi prueba. Se ejecuta como usuario normal de forma predeterminada. Sin embargo, el intervalo de sondeo de los servidores NTP aumenta hasta 2048 segundos, por lo que una suspensión/reanudación no se detectaría hasta 34 minutos después de la reanudación en el peor de los casos. Esto no parece ser configurable. Además, he observado que timesyncd retrocede el tiempo, lo que causa los mismos problemas que llamar a ntpdate en un cron (ver arriba).

chrony resuelve el problema. Openntpd no es adecuado porque su tasa de corrección es demasiado baja y no parece ser configurable. systemd-timesyncd tampoco resuelve completamente el problema, porque su intervalo de sondeo no es configurable.

Probé las siguientes versiones Debian de los demonios NTP: openntpd 20080406p-10, chrony 1.30-1 y systemd 215-5+b1.

Answer

El problema

Tengo el mismo problema y no he encontrado una buena solución. Esto es lo que encontré:

El problema es que después de la reanudación, los tiempos del reloj del sistema y del hardware del invitado son diferentes:

root@guest:~# date; hwclock
Sat Oct 11 13:09:38 UTC 2014
Sat Oct 11 13:10:42 2014  -0.454380 seconds

Sobre el anfitrión, coinciden:

root@four:~# date; hwclock
Sat Oct 11 13:11:35 UTC 2014
Sat Oct 11 13:11:36 2014  -1.000372 seconds

La solución sería ejecutar hwclock --hctosysel invitado después de que se haya reanudado. Sin embargo, no he encontrado una manera de hacer esto solo con cambios en el sistema invitado, ya que el invitado no se da cuenta de que está suspendido y reanudado.

Agente invitado de QEmu

Existe la posibilidad de ejecutar un software llamadoAgente invitado de QEmuen el invitado y notificar desde el host para actualizar el reloj del sistema invitado desde el reloj del hardware invitado. Sin embargo, la página menciona que elEl agente invitado hace que el anfitrión y el invitado sean vulnerables a los ataques.entre sí debido a problemas con un analizador JSON (al menos creo que el código afectado también se ejecuta en el host, no estoy seguro de eso). De todos modos, aquí se explica cómo configurarlo:

Configure un canal serie virtio para el agente como se menciona en lalibvirtwiki(ver tambiéndocumentación del formato de dominio libvirt).
Una vez que el canal serie esté disponible, instale e inicie QEmu Guest Agent en el invitado. (Debian:. apt-get install --no-install-recommends qemu-guest-agent)
Active el reloj compensado suspendiendo, esperando y reanudando. Luego ejecute el siguiente comando en el host para corregirlo: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'La página wiki que usa virsh qemu-agent-commandessin apoyo, pero no he encontrado ningún otro comando que haga el trabajo.

Encontré dos discusiones sobre la automatización dentro de libvirt de la llamada al guest-set-timecurrículum desde la suspensión:

http://thread.gmane.org/gmane.comp.emulators.libvirt/92431(Febrero 2014)
http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051(septiembre de 2014)

Sin embargo, hasta donde pude ver, todavía no se ha implementado nada.

Encontré información sobre cómo enviar comandos al agente invitado enwiki de stoney-cloud.org.

También he intentado configurar tickpolicy="catchup"en elconfiguración del temporizador libvirtpero esto no resolvió el problema.

NTP

Una alternativa al uso del agente sería utilizar un demonio ntp o llamar a ntpdate periódicamente desde un trabajo cron. No recomendaría esto último, ya que puede hacer que el tiempo retroceda, lo que puede confundir a los programas (por ejemplo, elEl servidor IMAP de Dovecot no intenta manejar el tiempo hacia atrásy puede rescindir).

Probé los siguientes demonios ntp:

abrirntpd: Corrige el tiempo muy lentamente a un ritmo de aproximadamente 2 segundos cada 60 minutos en mi prueba. El desfase de tiempo fue de 120 segundos. También,abrirntpdarroja un error si el desplazamiento de tiempo es demasiado grande y, en mi prueba, no corrige por completo el tiempo en ese caso. Ventajas de openntpd: Puede ejecutarse como usuario normal en chroot.
crono: Corrige un desfase de tiempo de 120 segundos en 30 minutos en mi prueba. chrony se puede configurar para ejecutarse como usuario normal. El soporte chroot no está implementado. El intervalo de sondeo del servidor NTP se puede configurar para cada servidor NTP.
systemd-timesyncd: Corrige un desplazamiento de tiempo de 120 segundos en 30 segundos en mi prueba. Se ejecuta como usuario normal de forma predeterminada. Sin embargo, el intervalo de sondeo de los servidores NTP aumenta hasta 2048 segundos, por lo que una suspensión/reanudación no se detectaría hasta 34 minutos después de la reanudación en el peor de los casos. Esto no parece ser configurable. Además, he observado que timesyncd retrocede el tiempo, lo que causa los mismos problemas que llamar a ntpdate en un cron (ver arriba).

chrony resuelve el problema. Openntpd no es adecuado porque su tasa de corrección es demasiado baja y no parece ser configurable. systemd-timesyncd tampoco resuelve completamente el problema, porque su intervalo de sondeo no es configurable.

Probé las siguientes versiones Debian de los demonios NTP: openntpd 20080406p-10, chrony 1.30-1 y systemd 215-5+b1.

Question 2

Muchas operaciones del host de virtualización en el invitado pueden provocar una pausa o una reanudación. Esto afectará negativamente al reloj del sistema del huésped. Por ejemplo, la clonación de una máquina virtual provoca una pausa durante la clonación. El reloj de invitados después está atrasado. Para que NTP sincronice el reloj, debe reiniciar el invitado; seguro que no es una buena solución en todos los casos. Como alternativa, podría simplemente reiniciar ntpd en el invitado, pero eso tampoco es óptimo. Idealmente, es necesario que haya un evento (VM reanudado) disponible que pueda usar opcionalmente para este tipo de corrección para el invitado.

Después de pasar algún tiempo investigando esto, decidí usar el reloj del host directamente como referencia para el reloj del sistema operativo invitado CentOS 7.

En lugar de ejecutar ntpd en el invitado, decidí que cada 15 minutos configuraría, mediante crontab, el reloj del sistema invitado desde el reloj del hardware del invitado. El reloj del hardware del invitado refleja la hora en el host de virtualización que se controla mediante ntpd que se ejecuta en el host de virtualización. Esto me proporciona tiempo confiable en el sistema operativo invitado. En el peor de los casos, el reloj puede estar apagado por hasta 15 minutos antes de sincronizarse con la hora adecuada después de reanudar la atención del huésped.

# crontab -e

0,15,30,45 * * * * /sbin/hwclock --hctosys

Sería mucho mejor tener un evento disponible para el invitado que iniciaría una sincronización horaria cuando se reanudara el invitado, pero aparentemente eso no está disponible. El enfoque crontab es una solución alternativa ya que realiza una llamada a hwclock cada 15 minutos. Hace el trabajo, pero no tan elegantemente como me gustaría.

Answer

Muchas operaciones del host de virtualización en el invitado pueden provocar una pausa o una reanudación. Esto afectará negativamente al reloj del sistema del huésped. Por ejemplo, la clonación de una máquina virtual provoca una pausa durante la clonación. El reloj de invitados después está atrasado. Para que NTP sincronice el reloj, debe reiniciar el invitado; seguro que no es una buena solución en todos los casos. Como alternativa, podría simplemente reiniciar ntpd en el invitado, pero eso tampoco es óptimo. Idealmente, es necesario que haya un evento (VM reanudado) disponible que pueda usar opcionalmente para este tipo de corrección para el invitado.

Después de pasar algún tiempo investigando esto, decidí usar el reloj del host directamente como referencia para el reloj del sistema operativo invitado CentOS 7.

En lugar de ejecutar ntpd en el invitado, decidí que cada 15 minutos configuraría, mediante crontab, el reloj del sistema invitado desde el reloj del hardware del invitado. El reloj del hardware del invitado refleja la hora en el host de virtualización que se controla mediante ntpd que se ejecuta en el host de virtualización. Esto me proporciona tiempo confiable en el sistema operativo invitado. En el peor de los casos, el reloj puede estar apagado por hasta 15 minutos antes de sincronizarse con la hora adecuada después de reanudar la atención del huésped.

# crontab -e

0,15,30,45 * * * * /sbin/hwclock --hctosys

Sería mucho mejor tener un evento disponible para el invitado que iniciaría una sincronización horaria cuando se reanudara el invitado, pero aparentemente eso no está disponible. El enfoque crontab es una solución alternativa ya que realiza una llamada a hwclock cada 15 minutos. Hace el trabajo, pero no tan elegantemente como me gustaría.

Question 3

libvirt admite la sincronización de la hora de los invitados desde2015. En Debian Stretch y luego busque la opción SYNC_TIMEen /etc/default/libvirt-guests:

# If non-zero, try to sync guest time on domain resume. Be aware, that
# this requires guest agent with support for time synchronization
# running in the guest. For instance, qemu-ga doesn't support guest time
# synchronization on Windows guests, but Linux ones. By default, this
# functionality is turned off.
#SYNC_TIME=1

Puede probar la sincronización de la hora desde el sistema host con:

virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'

Este comando debería regresar {"return":{}}si tiene éxito.

Answer

libvirt admite la sincronización de la hora de los invitados desde2015. En Debian Stretch y luego busque la opción SYNC_TIMEen /etc/default/libvirt-guests:

# If non-zero, try to sync guest time on domain resume. Be aware, that
# this requires guest agent with support for time synchronization
# running in the guest. For instance, qemu-ga doesn't support guest time
# synchronization on Windows guests, but Linux ones. By default, this
# functionality is turned off.
#SYNC_TIME=1

Puede probar la sincronización de la hora desde el sistema host con:

virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'

Este comando debería regresar {"return":{}}si tiene éxito.

Question 4

Desde Linux Kernel 4.11 existe PTP-KVM(Protocolo de tiempo de precisión - Máquina virtual del kernel):PTPes comparable aNTP, pero con mayor precisión y para red local. El sistema host Linux exporta su hora actual a cualquier sistema invitado para una lectura eficiente como /dev/ptp_kvm(o /dev/ptp0). cronoes capaz de usar eso dentro de la VM:

modprobe ptp_kvm
echo ptp_kvm >/etc/modules-load.d/ptp_kvm.conf
apt-get install chrony
echo "refclock PHC /dev/ptp0 poll 2" >/etc/chrony/conf.d/ptp.conf
systemctl restart chronyd

Como requisito, la hora del host también debe estar sincronizada.

Es posible que también desee configurar makestep 10 -dependiendo de qué diferencia esté dispuesto a tolerar: para este ejemplo, una diferencia inferior a 10 segundos se ajustaría acelerando el reloj de la VM, mientras que las diferencias más grandes se corregirían con todas las (malas) consecuencias.

Encontré esto en elDocumentación de RedHat, así que felicitaciones a ellos.

Answer

Desde Linux Kernel 4.11 existe PTP-KVM(Protocolo de tiempo de precisión - Máquina virtual del kernel):PTPes comparable aNTP, pero con mayor precisión y para red local. El sistema host Linux exporta su hora actual a cualquier sistema invitado para una lectura eficiente como /dev/ptp_kvm(o /dev/ptp0). cronoes capaz de usar eso dentro de la VM:

modprobe ptp_kvm
echo ptp_kvm >/etc/modules-load.d/ptp_kvm.conf
apt-get install chrony
echo "refclock PHC /dev/ptp0 poll 2" >/etc/chrony/conf.d/ptp.conf
systemctl restart chronyd

Como requisito, la hora del host también debe estar sincronizada.

Es posible que también desee configurar makestep 10 -dependiendo de qué diferencia esté dispuesto a tolerar: para este ejemplo, una diferencia inferior a 10 segundos se ajustaría acelerando el reloj de la VM, mientras que las diferencias más grandes se corregirían con todas las (malas) consecuencias.

Encontré esto en elDocumentación de RedHat, así que felicitaciones a ellos.

El problema

Respuesta1

El problema

Agente invitado de QEmu

NTP

Respuesta2

Respuesta3

Respuesta4

información relacionada