No meu host estou usando libvirt e um convidado KVM. Quando o host está sendo desligado, a libvirt suspende o convidado. Quando o host está inicializando, a libvirt retoma o convidado. O problema é que, se o hóspede for suspenso e retomado após 24 horas, por exemplo, o horário do hóspede será 24 horas atrás.
Achei que talvez o problema fosse com o clocksource, mas ele já está configurado para "kvm-clock".
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
Responder1
O problema
Estou com o mesmo problema e não encontrei uma boa solução. Aqui está o que encontrei:
O problema é que após a retomada, os horários do sistema e do hardware do convidado são diferentes:
root@guest:~# date; hwclock
Sat Oct 11 13:09:38 UTC 2014
Sat Oct 11 13:10:42 2014 -0.454380 seconds
No host, eles concordam:
root@four:~# date; hwclock
Sat Oct 11 13:11:35 UTC 2014
Sat Oct 11 13:11:36 2014 -1.000372 seconds
A solução seria executar hwclock --hctosysno convidado após ele ser retomado. Porém, não encontrei uma maneira de fazer isso apenas com alterações no sistema convidado, pois o convidado não percebe que ele foi suspenso e retomado.
Agente convidado QEmu
Existe a possibilidade de executar um software chamadoAgente convidado QEmuno convidado e notificar o host para atualizar o relógio do sistema convidado a partir do relógio do hardware convidado. No entanto, a página menciona que oagente convidado torna o host e o convidado vulneráveis a ataquesuns dos outros devido a problemas com um analisador JSON (pelo menos acredito que o código afetado também é executado no host, não tenho certeza disso). De qualquer forma, veja como configurar isso:
Configure um canal serial virtio para o agente conforme mencionado nolibvirtwiki(Veja tambémdocumentação do formato de domínio libvirt).
Depois que o canal serial estiver disponível, instale e inicie o QEmu Guest Agent no convidado. (Debian:.
apt-get install --no-install-recommends qemu-guest-agent)Acione o deslocamento do relógio suspendendo, aguardando e retomando. Em seguida, execute o seguinte comando no host para corrigi-lo:
virsh qemu-agent-command backup '{"execute":"guest-set-time"}'A página wiki que está usandovirsh qemu-agent-commandésem suporte, mas não encontrei nenhum outro comando que faça o trabalho.
Encontrei duas discussões sobre como automatizar na libvirt a chamada para guest-set-timeretomar da suspensão:
- http://thread.gmane.org/gmane.comp.emulators.libvirt/92431(Fevereiro de 2014)
- http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051(setembro de 2014)
No entanto, nada foi implementado ainda, pelo que pude perceber.
Encontrei informações sobre como enviar comandos ao agente convidado emwiki de stoney-cloud.org.
Eu também tentei configurar tickpolicy="catchup"noconfiguração do temporizador libvirtmas isso não resolveu o problema.
NTP
Uma alternativa ao uso do agente seria usar um daemon ntp ou chamar ntpdate periodicamente a partir de um cron job. Eu não recomendaria o último, pois pode fazer com que o tempo retroceda, o que pode confundir os programas (por exemplo, oO servidor Dovecot IMAP não tenta lidar com o tempo retrocedendoe pode terminar).
Eu tentei os seguintes daemons NTP:
openntpd: corrige o tempo muito lentamente a uma taxa de cerca de 2 segundos a cada 60 minutos no meu teste. A diferença de tempo foi de 120 segundos. Também,openntpdgera um erro se o deslocamento de horário for muito grande e, em meu teste, falha completamente ao corrigir o horário nesse caso. Vantagens do openntpd: Pode ser executado como usuário normal no chroot.
crônica: corrige um deslocamento de tempo de 120 segundos em 30 minutos no meu teste. chrony pode ser configurado para ser executado como usuário normal. o suporte chroot não está implementado. O intervalo de pesquisa do servidor NTP pode ser configurado para cada servidor NTP.
systemd-timesyncd: corrige um deslocamento de tempo de 120 segundos em 30 segundos no meu teste. Executa como usuário normal por padrão. No entanto, o intervalo de sondagem dos servidores NTP aumenta até 2.048 segundos, de modo que uma suspensão/retomada não seria detectada até 34 minutos após a retomada, na pior das hipóteses. Isso não parece ser configurável. Além disso, observei o timesyncd retroceder no tempo, o que causa os mesmos problemas que chamar ntpdate em um cron (veja acima).
cronia resolve o problema. Openntpd não é adequado porque sua taxa de correção é muito baixa e não parece ser configurável. systemd-timesyncd também não resolve totalmente o problema, porque seu intervalo de pesquisa não é configurável.
Testei as seguintes versões Debian dos daemons NTP: openntpd 20080406p-10, chrony 1.30-1 e systemd 215-5+b1.
Responder2
Muitas operações do host de virtualização no convidado podem resultar em uma pausa - retomada. Isto afetará negativamente o relógio do sistema no convidado. Por exemplo, clonar uma VM resulta em uma pausa durante a clonagem. O relógio de convidados depois está atrasado. Para fazer com que o NTP sincronize o relógio, você precisa reiniciar o convidado - não é uma boa solução em todos os casos, com certeza. Alternativa, você pode simplesmente reiniciar o ntpd no convidado, mas isso também não é o ideal. Idealmente, é necessário que haja um evento (VM retomada) disponível que você possa usar opcionalmente para esse tipo de correção para o convidado.
Depois de passar algum tempo pesquisando isso, decidi usar o relógio do host diretamente como referência para o relógio do sistema operacional convidado CentOS 7.
Em vez de executar o ntpd no convidado, decidi que a cada 15 minutos eu definiria, via crontab, o relógio do sistema convidado a partir do relógio do hardware do convidado. O relógio de hardware do convidado reflete a hora no host de virtualização que é controlada pelo ntpd em execução no host de virtualização. Isso me proporciona um tempo confiável no sistema operacional convidado. Na pior das hipóteses, o relógio pode ficar desligado por até 15 minutos antes de ser sincronizado com o horário adequado após a retomada do hóspede.
# crontab -e
0,15,30,45 * * * * /sbin/hwclock --hctosys
Seria muito melhor ter um evento disponível no convidado que iniciasse uma sincronização de horário quando o convidado fosse retomado, mas aparentemente isso não está disponível. A abordagem crontab é uma solução alternativa, pois faz uma chamada de horário a cada 15 minutos. Ele faz o trabalho, mas não tão elegantemente quanto eu gostaria.
Responder3
libvirt suporta sincronização de horário de convidado desde2015. No Debian Stretch e posterior procure a opção SYNC_TIMEem /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
Você pode testar a sincronização de horário no sistema host com:
virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'
Este comando deve retornar {"return":{}}em caso de sucesso.
Responder4
Desde o Linux Kernel 4.11 existe PTP-KVM(Precision Time Protocol - Kernel Virtual Machine):PTPé comparável aNTP, mas com maior precisão e para rede local. O sistema host Linux exporta seu horário atual para qualquer sistema convidado para leitura eficiente como /dev/ptp_kvm(ou /dev/ptp0).
crônicaé capaz de usar isso dentro da 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, o horário no host também deve ser sincronizado.
Você também pode querer configurar makestep 10 -dependendo de qual diferença você está disposto a tolerar: para este exemplo, uma diferença abaixo de 10s seria ajustada acelerando o relógio da VM, enquanto diferenças maiores seriam pisoteadas com todas as (ruins) consequências.
Eu encontrei isso noDocumentação RedHat, então parabéns para eles.