Estou atormentado por um problema aparentemente simples, mas realmente problemático, por isso peço ajuda aqui.
Sintoma
Instalei uma instância do VMware ESXi 5.1 dentro da VMware Workstation para aprender sobre vários recursos do ESXi. Deixe-me chamá-lo de máquina vESXi. Meu problema de executar o vESXi é, toda vez que eu suspendo o vESXi durante a noite e retomá-lo no dia seguinte, o tempo em vESXi atrasa. Ou seja, se eu suspender o vESXi às 22:00 da noite anterior e retomar hoje de manhã, verei o vESXi informando que ainda são 22:00 da noite anterior. Eu sei que isso é normal porque um sistema de PC mantém seu tempo contando a interrupção do tick do timer do hardware. Então, eu decido que o vESXi use o NTP para sincronizar com um servidor NTP. Meu servidor NTP é um controlador de domínio do Windows Server 2003 em execução no mesmo segmento de rede local.
Eu rapidamente observo o problema: meu vESXi nunca sincroniza seu tempo com o servidor Window NTP, não importa quanto tempo eu espere.
Você pode sugerir que eu encerrei o vESXi em vez de suspendê-lo, mas realmente adoro o recurso de suspensão fornecido pelo VMware Workstation, que é realmente rápido e fluente.
Perguntas
Eulio link que fornece a solução alternativa (alguns ajustes para que funcione com o servidor NTP do Windows), mas esse artigo da KB cria mais defletores na primeira leitura. Além do mais, é realmente complicado ajustar todos os vESXi se eu tiver muitos deles.
Q1 (primário): O que na terra essas declarações significam?
By default, an unsynced Windows server chooses a 10-second dispersion
and adds to the dispersion on each poll interval that it remains in
sync. An ESXi/ESX host, by default, does not accept any NTP reply with
a root dispersion greater than 1.5 seconds.
Q2: o KB me diz para adicionar
tos maxdist 30
para o /etc/ntp.conf . O que essa linha significa? A página man do ntpd.conf link parece não dizer nada sobre tos ou maxdist .
Q3: Como o cliente ESXi NTP (daemon) não sincroniza com sucesso com o servidor NTP atribuído, o ESXi gera alguma mensagem de log explicando os detalhes?
Q4: Existe alguma maneira de forçar o cliente ntp do ESXi a sincronizar imediatamente com um servidor NTP específico? Até mesmo uma operação manual é bem-vinda. Eu não sei se o comando bundled ntpd pode fazer isso.
Q5: Sem um ajuste manual do /etc/ntp.conf no ESXi, que tipo de servidor NTP posso configurar para fornecer a fonte de tempo para a minha caixa do vESXi? Linux ntpd ou o que? qualquer configuração especial no lado do servidor é necessária?
Obrigado antecipadamente.
ATUALIZAÇÃO COM EXPERIÊNCIAS
Depois de ler FAQ NTP e fazendo algumas experiências, confirmei os seguintes fatos:
- Com o tweak KB1035833, o vESXi pode realmente sincronizar com o servidor NTP do Windows, mesmo que o tempo do vESXi esteja 7 dias atrás do servidor (apenas uma espera de 5 a 10 minutos).
- Usando o viclient para atribuir uma máquina Linux (openSUSE 11.4, pacote ntp 4.2.6 no meu caso) na minha rede local como servidor NTP, o vESXi sem o ajuste KB1035833 também pode sincronizar com o servidor NTP com apenas 5 a 10 - atraso de minutos, mesmo com atraso de 7 dias. Mas uma coisa que acho que tenho que ter em mente é que preciso marcar Reiniciar o serviço NTP para aplicar alterações no viclient para forçar a sincronização de tempo em breve (em 5 a 10 minutos). Em outras palavras, se eu não reiniciar o serviço NTP do ESXi, será muito difícil prever quanto tempo será necessário para obter a sincronização de horário após retomar o vESXi com um atraso de tempo noturno (às vezes custa uma hora ou mais) - - provavelmente porque o código do cliente NTP reiniciado considera o jitter do horário do servidor NTP inaceitável durante esse período.
Então: Meu problema prático com relação ao tempo de manutenção do vESXi foi resolvido (preferindo sincronizar o tempo com um servidor Linux NTP).
Agora o foco está no primeiro trimestre. O que há de errado com o servidor NTP do Windows? Espero que alguém possa ajudar a explicar essas duas afirmações no primeiro trimestre do ponto de vista do protocolo NTP.
Agradeço a quádruplebucky e ao Reality Extractor por suas informações úteis, embora suas respostas ao meu problema específico não sejam bem precisas.
