Preciso executar um servidor NTP em cada VM?

16

Os convidados não puderam herdar a hora do sistema do host?

Parece meio inútil executar o mesmo daemon para obter os mesmos resultados na mesma máquina várias vezes, mas não encontrei nada relacionado ao tempo ao ler artigos KVM ou Xen. Meu entendimento é que o convidado recebe o tempo de host na inicialização, mas pode se afastar. Isso está correto?

    
por zimbatm 16.03.2013 / 03:51

3 respostas

12

Isso está correto. Deve-se notar que o tempo não apenas "pode" se afastar, mas irá se afastar devido ao fato de que os intervalos entre as interrupções temporizadas (nas quais o sistema operacional frequentemente é baseado) são esticados e compactados hipervisor seria adequado.

Uma solução comum para a maioria das plataformas de virtualização (serviços de integração do Hyper-V, ferramentas VMWare) está executando um daemon no convidado que sincroniza periodicamente os relógios com o host da VM. Como observado por Hauke em um comentário à sua pergunta, o KVM também fornece um relógio paravirtualizado que precisaria do respectivo driver carregado no sistema operacional convidado para funcionar.

Leitura adicional:

Cronometragem em máquinas virtuais VMware (vmware.com)
Sincronização do relógio dos convidados do KVM (s19n.net)

    
por 16.03.2013 / 09:07
17

Em um mundo perfeito, seus convidados da VM manteriam o tempo perfeito, ou pelo menos tão perfeito quanto o host. Infelizmente não vivemos em um mundo perfeito.

Com base em minha experiência com praticamente todos os hipervisores conhecidos pelo homem, sempre executo um cliente NTP em máquinas virtuais, sem exceção. Minha configuração usual é ntpd com a opção -g ou ntpdate começando direito antes para sistemas antigos, para acelerar o relógio (que pode estar muito fora de sincronia na inicialização do sistema).

O KVM tem uma configuração quase perfeita, com seu relógio paravirtualizado em tempo real ; convidados com o driver apropriado (todos os Linux recentes, pelo menos) manterão o tempo, assim como o host. Mas ainda assim as coisas dão errado aqui: Por exemplo, o host pode não estar executando o NTP, o host pode ter um fuso horário incorreto configurado, o relógio do host pode estar simplesmente errado, etc.

O VMware e o Hyper-V estão no meio. Cada um tem uma ferramenta para ser executada no guest, que sincroniza o relógio com o host periodicamente, mas, novamente, isso é vulnerável a qualquer problema existente com o clock do host.

Os convidados do meu servidor Hyper-V de teste também exibiram um comportamento estranho: mesmo com serviços de integração, o relógio do convidado se movimentaria mais rápido que 500 ppm, evitando que o ntpd funcionasse ( considera o relógio insano se deriva mais rápido do que isso ). Eu tive que mudar esses convidados para chrony , o que permite que este valor a ser ajustado.

Xen é o pior a esse respeito; ele tem absolutamente nenhuma sincronização e a execução do NTP nos convidados é praticamente necessária. (Me disseram que versões muito recentes do Xen têm algum tipo de sincronização, mas ainda não trabalharam pessoalmente com ele.)

As coisas só pioram se o hipervisor de host não estiver sob seu controle, como uma nuvem pública. Você está à mercê do provedor com relação ao relógio do host e, se eles não forem diligentes em mantê-lo sincronizado, você perde.

Com tudo isso, a execução de clientes NTP em suas máquinas virtuais é muito necessária se você precisar mesmo de um relógio semi-preciso. NB: Se você executar máquinas virtuais Windows, obtenha um cliente NTP de terceiros que ajuste o relógio continuamente; A má desculpa para um cliente que vem com o Windows só ajusta o relógio uma vez por semana , o que é absolutamente ridículo.

    
por 17.03.2013 / 01:03
3

Eu recomendaria usar o NTP porque é bem conhecido e existe há muito tempo. Ajustar o relógio não é trivial. NTP resolveu este problema.

A linha oficial do VMware é usar um mecanismo, com o NTP preferido porque ele é mais refinado e executa etapas menores para ajustar o tempo. A solução interna da VMware toma medidas maiores. Quando você corre os dois, eles podem lutar entre si. Com a solução interna da VMware dando um grande passo e depois o NTP ajustando-o e levando-o de volta um pouco.

Na prática, no entanto, corremos os dois ao mesmo tempo e ainda não vi nenhum 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
    
por 16.12.2013 / 10:31