Como manter o tempo no convidado KVM reiniciado com libvirt?

Question

No meu host, estou usando o libvirt e um convidado do KVM. Quando o host está sendo encerrado, a libvirt suspende o convidado. Quando o host está inicializando, o libvirt retoma o convidado. O problema é que, se o convidado for suspenso e retomado após 24 horas, por exemplo, o horário do hóspede é de 24 horas no passado.

Eu pensei que talvez o problema seja com o clocksource, mas já está definido como "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

    

Answer 1

O problema

Eu tenho o mesmo problema e não encontrei uma boa solução. Aqui está o que eu encontrei:

O problema é que, após o reinício, os tempos do relógio do sistema e do hardware no 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 --hctosys no convidado depois que ele fosse retomado. No entanto, não encontrei uma maneira de fazer isso apenas com alterações no sistema convidado, pois o convidado não percebe que está suspenso e reiniciado.

QEmu Guest Agent

Existe a possibilidade de executar um software chamado QEmu Guest Agent no convidado e notificar o host para atualizar o relógio do sistema convidado a partir do relógio de hardware convidado. No entanto, a página menciona que o agente convidado torna o host e o convidado vulneráveis a ataques um do outro devido a problemas com um analisador JSON (pelo menos, acredito que o código afetado também seja executado no host, Não tenho certeza sobre isso). De qualquer forma, veja como configurar isso:

1. Configure um canal serial virtio para o agente, como mencionado no wiki libvirt (veja também documentação do formato de domínio libvirt ).

2. 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 .)

3. 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 da wiki que usa virsh qemu-agent-command é sem suporte , mas não encontrei nenhum outro comando que faça o trabalho.

Eu encontrei duas discussões sobre como automatizar dentro da libvirt a chamada para guest-set-time no currículo da suspensão:

• link (fevereiro de 2014)
• link (setembro de 2014)

No entanto, nada foi implementado até onde pude ver.

Encontrei informações sobre como enviar comandos para o agente convidado em wiki de stoney-cloud.org .

Eu também tentei definir tickpolicy="catchup" na configuração do temporizador libvirt , mas isso não resolveu o problema.

NTP

Uma alternativa ao uso do agente seria usar um daemon ntp ou chamar o ntpdate periodicamente a partir de um cron job. Eu não recomendaria este último, pois ele pode causar um retrocesso no tempo, o que pode confundir programas (por exemplo, o servidor Dovecot IMAP não faz isso) t tente lidar com o tempo que vai para trás e pode terminar).

Eu tentei os seguintes daemons ntp:

• openntpd : Corrige o tempo muito lentamente a uma taxa de cerca de 2 segundos por 60 minutos no meu teste. O deslocamento de tempo foi de 120 segundos. Além disso, openntpd gera um erro se o deslocamento de tempo for muito grande e, no meu teste , falha completamente em corrigir o tempo nesse caso. Vantagens do openntpd: Pode ser executado como usuário regular no chroot.

• chrony : Corrige um deslocamento de tempo de 120 segundos em 30 minutos no meu teste. O chrony pode ser configurado para ser executado como usuário regular. O suporte a 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. Funciona como usuário regular por padrão. No entanto, o intervalo de pesquisa de servidores NTP aumenta até 2048 segundos, de modo que uma suspensão / retomada não seria detectada até 34 minutos após o reinício no pior dos casos. Isso não parece ser configurável. Além disso, observei o timesyncd rebaixando o tempo, o que causa os mesmos problemas que chamar o ntpdate em um cron (veja acima).

chrony resolve o problema. Openntpd não é adequado porque sua taxa de correção é muito baixa e não parece configurável. systemd-timesyncd não resolve totalmente o problema, porque o seu intervalo de pesquisa não é configurável.

Eu testei as seguintes versões Debian dos daemons NTP: openntpd 20080406p-10, chrony 1.30-1 e systemd 215-5 + b1.

    

Answer 2

O kvm-clock sincroniza o horário do convidado para hospedar o horário na inicialização do convidado . Você deve usar e ntp client no guest e shutdown / startup em vez de usar suspend / resume.

    

Answer 3

Muitas operações do host de virtualização no convidado podem resultar em pausa - retomada. Isso 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 convidado depois está atrasado. Para 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ê poderia apenas reiniciar o ntpd no guest, mas isso também não é o ideal. O ideal é que haja um evento (VM retomado) 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 clock do host diretamente como referência para o relógio do sistema operacional OS do CentOS 7 guests.

Em vez de executar o ntpd no guest, decidi que a cada 15 minutos eu definiria, por meio do crontab, o clock do sistema guest a partir do clock do hardware do convidado. O relógio de hardware do convidado reflete o tempo no host de virtualização que é controlado 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 estar desligado por até 15 minutos antes de ser sincronizado no tempo adequado após a retomada do convidado.

# 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 tempo quando o convidado fosse retomado, mas aparentemente isso não está disponível. A abordagem crontab é uma solução alternativa, pois faz uma chamada hwclock a cada 15 minutos. Faz o trabalho, mas não tão elegantemente quanto eu gostaria.

    

Answer 4

O libvirt é compatível com a sincronização de horário dos hóspedes desde 2015 . No Debian Stretch e depois procure pela opção SYNC_TIME in /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 a partir do sistema host com:

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

Este comando deve retornar {"return":{}} no sucesso.

    

Answer 5

Eu uso uma maneira similar para sincronizar o tempo após a suspensão / retomada da VM, mas acho melhor tentar adivinhar, que ela deve sincronizar na direção correta e é maior do que a pequena diferença, que pode ser corrigida pelo NTPD.

link

PS. O novo changelog do centos 6.7 diz que isso pode ser feito automaticamente com apenas uma fonte de relógio kvm-clock.