Descrição

O plug-in de verificação de integridade Nutanix NCC check_ntp verifica a configuração NTP dos CVMs (VMs do controlador) e dos hosts do hipervisor. Ele também verifica se há desvios de tempo no cluster.

O plug-in check_ntp contém várias verificações individuais que se concentram em cenários específicos relacionados ao NTP:

• Sincronização de horário CVM/PCVM NTP - determina se o CVM/PCVM é capaz de sincronizar o horário com qualquer um dos servidores NTP configurados
• Sincronização de horário NTP do hipervisor (somente AHV + ESXi) - determina se o host é capaz de sincronizar o horário com qualquer um dos servidores NTP configurados

Nota: Verificação de configuração NTP, ID de verificação 103076 foi retirada no NCC versão 4.0.0.

Este plug-in também é executado no Prism Central (PC), exceto para a verificação do hipervisor.

Este plug-in de verificação de integridade foi introduzido no NCC versão 3.1 e converge todas as verificações NTP das versões anteriores do NCC. No Prism Central, essa verificação foi introduzida no NCC versão 3.5.3. A função de alerta dessas verificações foi introduzida no NCC 3.6.2.

Causas Possíveis

Se esta verificação de integridade retornar um resultado não APROVADO, as possíveis causas são as seguintes:

• Não há servidores NTP configurados no cluster.
• Não há servidores NTP configurados no hypervisor.
• Todos ou alguns servidores NTP configurados no hypervisor não são iguais aos configurados nos CVMs ou PC VMs.
• Um servidor NTP configurado não está acessível ou não responde às consultas NTP.
• Um servidor NTP configurado não é confiável ou estável.
• O servidor NTP está configurado com um nome de host, mas não pode ser resolvido devido a problemas de resolução de DNS/nome.
• A porta NTP (UDP/123) não está aberta.
• A hora no cluster está fora de sincronia e está no futuro em pelo menos 5 segundos em comparação com a hora real nos servidores NTP.
• O servidor NTP está passando um parâmetro que o cliente NTP do CVM ou PC VM considera inadequado para sincronização NTP, como um alto valor de dispersão, deslocamento, jitter, alcance ou estrato.
• Um servidor NTP baseado em Windows (AD PDC) que usa seu relógio local como fonte de horário, por padrão, se anunciará como uma fonte NTP menos adequada, incluindo um valor de dispersão de 10 segundos no parâmetro NTP desse servidor. O W32time não foi projetado com a precisão necessária para NTP e não garante tolerância superior a +/- 5 minutos.
• O serviço genesis foi reiniciado recentemente e a sincronização NTP ainda está pendente, ou se a configuração NTP foi alterada, o efeito pode demorar algum tempo. De acordo com o protocolo NTP, leva cerca de 5 minutos (cinco boas amostras) até que um servidor NTP seja aceito como fonte de sincronização. Esperar e executar novamente a verificação após 10 a 15 minutos pode produzir um resultado diferente se houver tempo suficiente para que a alteração entre em vigor e seja sincronizada.

  Por exemplo, após reiniciar o genesis, o comando ntpq mostra que a hora ainda está sincronizando com .LOCL.

Então, depois de esperar 10-15 minutos, o comando ntpq agora mostra:

Portanto, executar novamente a verificação imediatamente falhará, mas executá-la novamente após algum tempo, digamos 10 a 15 minutos, deve PASSAR.

Sintomas e impacto

Se essa verificação de integridade retornar um resultado não APROVADO, a operação do cluster pode estar em risco de vários sintomas/impactos, como:

• Os usuários não conseguem fazer logon no console da web Prism usando LDAP ou outros serviços integrados de diretório.
• O cluster não consegue iniciar ou funcionar corretamente devido a uma grande distorção de tempo após uma interrupção ou manutenção.
• Log impreciso e coleta de logs.
• Resultados imprecisos da verificação de integridade dependem de prazos precisos e correlação de eventos.
• Gráficos incorretos e distorcidos no Prism.
• VMs de usuário iniciando em hosts de hipervisor com RTC (relógios em tempo real) imprecisos, causando distorção de horário do sistema operacional convidado.
• Produtos de software de backup de terceiros, como Veeam ou Commvault, estão tendo problemas para interagir com o cluster.
• Instantâneos expirando muito cedo ou muito tarde quando o tempo entre um cluster e um site remoto está fora de sincronia

Executando a verificação do NCC

Execute esta verificação como parte das verificações de integridade NCC completas:

Ou execute esta verificação individualmente:

Você também pode executar as verificações na página de integridade do console da Web do Prism: selecione Ações > Executar verificações. Selecione Todas as verificações e clique em Executar.

Saída de amostra

Para status: INFORMAÇÕES

Para status: FALHA

Para status: ERR

De NCC-4.0.0 em diante para status: WARN

Mensagem de saída

Observação : o ID de verificação 103076 foi desativado no NCC versão 4.0.0.

Solução

Para clusters que executam ESXi 7.0.3 build 19193900, a verificação dará um falso positivo mesmo depois que os servidores NTP configurados no host e Prism UI forem os mesmos.

Atualize para NCC-4.5.0.1 para mitigar o falso positivo.

Etapas gerais de solução de problemas

Se esta verificação retornar um resultado não APROVADO, verifique o seguinte:

• Pelo menos um, mas preferencialmente três ou mais servidores NTP confiáveis fora do cluster são configurados no cluster (CVMs/PCVMs) E nos hosts (hypervisors - AHV, ESXi, Hyper-V, XenServer).
  • Para configurar servidores NTP nos CVMs e AHV, consulte Configuring NTP Servers no Prism Web Console Guide . (A configuração de servidores NTP via Prism atualizará os CVMs e os hosts AHV).
  • Para configurar servidores NTP em hosts ESXi, consulte Configuring Network Time Protocol (NTP) on ESX/ESXi hosts using the vSphere Client (2012069) .
  • Para configurar servidores NTP em hosts Hyper-V, consulte Configurando NTP no Hyper-V abaixo.
  • Para obter recomendações sobre quais servidores NTP usar, consulte Recomendações para sincronização de horário .
• A lista de servidores NTP configurados nos hipervisores deve preferencialmente ser a mesma que os configurados nos CVMs.
• Se o servidor NTP for definido usando o FQDN ou o nome do host, verifique se o cluster pode resolver o endereço IP do NTP FQDN em todos os servidores de nome DNS configurados. Uma configuração de servidor de nome inválida no Prism pode impedir que os servidores NTP sejam usados e levar a problemas de sincronização de tempo.
• A porta de destino do protocolo NTP (UDP 123) está aberta para os servidores NTP de destino por meio de quaisquer ACLs/firewalls no caminho de rede entre todos os CVMs/hosts e os servidores NTP.
• Tente fazer ping nos servidores NTP usando FQDN e endereços IP para estabelecer conectividade de rede básica. Esteja ciente de que alguns ACLs/firewalls podem bloquear intencionalmente o tráfego de ping (eco ICMP), mas ainda permitir UDP/123, portanto, considere que um resultado inacessível não é necessariamente uma causa raiz, mas uma possível percepção dos problemas de conectividade de rede. Use a próxima etapa para validar mais.
• Independentemente da acessibilidade do servidor NTP por ping na rede, certifique-se de que ele esteja íntegro e respondendo na camada do aplicativo com consultas NTP válidas e utilizáveis e que retorne informações de tempo precisas. Você pode verificar se as consultas NTP retornam informações de tempo executando o seguinte comando:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• Verifique o status da sincronização NTP em todos os CVMs e hosts usando o procedimento Revisando a saída do comando "ntpq -pn" abaixo.
• Verifique a configuração NTP em todos os hosts usando o procedimento Revendo o conteúdo do arquivo ntp.conf abaixo.
• Esta verificação pode produzir um resultado não APROVADO após a configuração do NTP se o horário ainda não tiver sido sincronizado com a configuração NTP nova/atualizada. Se o servidor NTP foi adicionado recentemente e o tempo CVM não é considerado no futuro (compensação negativa do servidor NTP), esta verificação pode ser acionada até que o protocolo NTP tenha encontrado uma fonte NTP estável e adequada e o CVM tenha sincronizado com sucesso (~10 minutos).
• Se os servidores NTP configurados não forem fontes stratum 0 confiáveis (GPS/relógio atômico), eles devem ter uma fonte de horário externa de estrato adequado (0-3 é bom) configurado e não devem estar sincronizados com o relógio local do esse servidor ou uma fonte de horário interna.

Notas:

• A sincronização de um cluster Nutanix AOS/PC com uma fonte de tempo baseada no Windows é conhecida por causar problemas ao longo de um período de tempo. Consulte KB 3851 Solucionando problemas de sincronização NTP para servidores de horário do Windows .
  A Nutanix recomenda que você não sincronize o horário de um cluster com fontes de horário do Windows . Em vez disso, use fontes de horário confiáveis que não sejam Windows . Consulte Recomendações para Sincronização de Tempo no Guia Prism Web Console .
• Não use um servidor NTP como fonte para um cluster Nutanix e/ou hipervisor se o servidor NTP real for uma VM de usuário em execução como convidada no mesmo cluster! Isso não é confiável, imprevisível na VM do usuário e interrupções e reinicializações do cluster e não é recomendado.
• Você não precisa configurar os servidores NTP nos hosts AHV manualmente. A configuração de servidores NTP via Prism/ncli atualizará os CVMs e os hosts AHV.
• Ao usar o console da web Prism ou ncli para adicionar os servidores NTP em um cluster AOS baseado em ESXi, os servidores NTP não são adicionados automaticamente ao arquivo /etc/ntp.conf do host. Depois de adicionar os servidores NTP no Prism, você também deve configurar manualmente esses servidores NTP nos hosts ESXi. Para obter mais informações sobre como configurar servidores NTP nos hosts ESXi, consulte Configuring Network Time Protocol (NTP) on ESX/ESXi hosts using the vSphere Client (2012069) .
• Em um cluster de hipervisor misto (AHV + ESXi), conforme mencionado acima, os hosts AHV serão configurados via Prism, mas você deve configurar manualmente os servidores NTP nos hosts ESXi do cluster de hipervisor misto.
• Em um cluster Hyper-V, o plug-in check_ntp valida apenas a configuração CVM NTP. Ele não verifica o NTP ou a configuração de tempo dos hosts do Windows Hyper-V, portanto, a verificação não resulta em um status FAIL se o hipervisor estiver configurado incorretamente ou estiver fora de sincronia com as fontes NTP e/ou AD PDC. Confirme manualmente se os hosts do Hyper-V e os controladores de domínio têm uma hierarquia de tempo saudável Windows . O(s) AD PDC(s) deve(m) usar fontes de tempo upstream NTP confiáveis em paralelo aos CVMs, potencialmente os mesmos servidores NTP (veja o próximo ponto).
• Idealmente, para simplificar a comparação de logs e evitar a triagem complexa de problemas de sincronização de tempo, os hipervisores e as VMs do controlador devem usar os mesmos servidores NTP. Se os hipervisores e as VMs do controlador estiverem usando servidores NTP diferentes, essa verificação de integridade pode produzir uma saída INFO para aumentar a conscientização e garantir que essa seja uma configuração consciente e razoável, em oposição a uma configuração incorreta acidental e para destacar rapidamente esse fato durante qualquer outra solução de problemas não relacionada caso ocorra a qualquer momento durante a produção dos clusters.

Para obter mais informações e práticas recomendadas sobre a sincronização de horário do cluster Nutanix, consulte Cluster Time Synchronization no Prism Web Console Guide no Nutanix Support Portal .

Etapas específicas de solução de problemas

• Se a verificação relatar "INFO: os servidores NTP configurados no hipervisor xxxx diferem daqueles configurados na configuração do Zeus xxxx", configure os mesmos servidores NTP no cluster, bem como os hipervisores.
• Se a verificação relatar "FALHA: o líder NTP não está sincronizando com nenhum servidor NTP externo porque o tempo do cluster está no futuro em relação aos servidores NTP externos: xxxx", o cluster pode ter sido iniciado sem um status de sincronização NTP válido e puxando o retrocesso do tempo CVM pode afetar as operações de metadados de armazenamento em andamento. Para resolver esse problema específico de horário CVM futuro, registre um caso no Suporte da Nutanix para obter mais assistência e não altere manualmente nenhuma data/hora CVM.
• Se a verificação informar "FALHA: o líder NTP não está sincronizando com nenhum servidor NTP externo", siga as etapas gerais de solução de problemas acima. Caso as etapas mencionadas acima não resolvam o problema, registre um caso com o Nutanix Support , fornecendo os resultados e qualquer resultado da solução de problemas gerais e da configuração atual do cluster NTP.
• Se a verificação informar "FALHA: o hipervisor não está sincronizando com nenhum servidor NTP", siga as etapas gerais de solução de problemas acima. Caso as etapas mencionadas acima não resolvam o problema, siga as etapas abaixo:
  1. No host, reinicie o serviço ntpd usando o procedimento Reiniciando o serviço ntpd descrito abaixo.
  2. Verifique se o host agora está sincronizando o horário com o NTP usando o procedimento Revisando a saída do comando "ntpq -pn" abaixo. Certifique-se de esperar cerca de 10 minutos para sincronizar.
  3. Se nem todos os hosts estiverem sincronizando corretamente, siga o procedimento Revendo o conteúdo do arquivo ntp.conf abaixo.
  4. Se o problema ainda não for resolvido, considere entrar em contato com o Suporte da Nutanix , fornecendo os resultados e qualquer resultado da solução de problemas gerais e da configuração NTP do cluster atual.
• Se a verificação relatar "FALHA: Este CVM é o líder NTP, mas não está sincronizando o horário com nenhum servidor NTP externo" e você verificou que o servidor NTP foi definido:
  1. O(s) servidor(es) NTP configurado(s) pode(m) estar sobrecarregado(s) e/ou limitando propositadamente a taxa do número de solicitações de cliente NTP para responder para se proteger de DDoS (acidental ou não), portanto, não respondendo a solicitações NTP válidas pelo líder CVM NTP. Você pode investigar se seu servidor NTP está limitando a taxa das solicitações inspecionando o arquivo de log do serviço CVM genesis para uma entrada de linha de erro contendo " resposta de limite de taxa do servidor ":
     nutanix@cvm$ allssh "grep -A 1 -i 'limite de taxa' ~/data/logs/genesis.out | tail"
     ...
     2018-12-12 11:03:14 ERRO node_manager.py:3941 A atualização do Systime com ntpdate falhou com o erro: 1: 12 Dec 11:03:14 ntpdate[26695]: nnn101 rate limit response from server.
     12/12/2018 11:03:14 ntpdate[26695]: nenhum servidor adequado para sincronização encontrado
     1. Se você não controlar o servidor NTP afetado, remova-o da configuração NTP do Prism e adicione um servidor NTP diferente e mais confiável.
     2. Se você controlar a configuração do servidor NTP de origem, considere adicionar exceções de restrição para os IPs CVM/host. Consulte a documentação do seu servidor NTP para obter detalhes. Por exemplo, em um serviço ntpd baseado em Linux, a seguinte linha precisaria ser adicionada ao arquivo /etc/ntp.conf do servidor NTP e então recarregada:
        restringir mascarar
  2. O horário do CVM pode estar à frente do horário do servidor NTP, e o serviço de gênese do CVM impedirá intencionalmente a sincronização do NTP. Isso pode ser mais evidenciado nos logs do Genesis do CVM afetados, executando o seguinte comando e procurando um deslocamento negativo entre o CVM e a fonte NTP:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | tail"
     Saída de exemplo:
     2019-02-03 22:42:11 INFO node_manager.py:2314 Consultando servidores NTP upstream: 10.xx11
     2019-02-03 22:42:12 INFO node_manager.py:2334 NTP offset: -89.328 segundos
     2019-02-03 22:42:12 INFO node_manager.py:2354 O tempo está à frente do servidor NTP externo em 89,328 segundos, não sincronizando o tempo enquanto os serviços de cluster estão em execução
     2019-02-03 22:42:12 INFO node_manager.py:2230 Reiniciando o servidor NTP.
     2019-02-03 23:02:13 ERRO node_manager.py:2450 NTP externo ainda inutilizável (0)
     2019-02-03 23:02:13 AVISO node_manager.py:2456 Desativando servidores NTP upstream
     2019-02-03 23:02:13 INFO node_manager.py:2202 Parando o servidor NTP.
     2019-02-03 23:02:13 INFO node_manager.py:2230 Reiniciando o servidor NTP.
     2019-02-03 23:12:13 INFO node_manager.py:2314 Consultando servidores NTP upstream: 10.xx11
     2019-02-03 23:12:13 INFO node_manager.py:2334 NTP offset: -89.297 segundos
     
     Na saída de exemplo acima, o cluster não está sincronizando com um servidor NTP recém-adicionado. Nesta situação, o servidor NTP está rodando 89 segundos atrás do CVM e, portanto, é considerado inutilizável como fonte NTP.
     Importante: Se a hora CVM estiver no futuro, NÃO acerte o relógio manualmente ! Entre em contato com o suporte da Nutanix para obter assistência e forneça a saída acima.
• Se a verificação relatar "ERR: Failed to run ntpq on the host": Execute o seguinte comando em cada CVM e assegure-se de que o comando seja executado com êxito.
  nutanix@cvm$ ntpq -pn

  Se o comando falhar na execução ou a verificação NCC relatar um status ERR novamente, investigue os CVMs para obter memória livre. Registre um caso com o Suporte da Nutanix para obter mais assistência.

Revendo a saída do comando " ntpq -pn "

O comando ' ntpq -pn ' é o comando principal usado por esta verificação para identificar o status de sincronização NTP do CVM ou do host.

Cada linha dos resultados terá o formato: (Apenas saída de exemplo. IPs reais, linhas de servidores NTP e valores relacionados serão diferentes com base nas configurações individuais)

Onde remoto é o ponto remoto ou servidor que está sendo sincronizado. “127.127.1.0 LOCL” é este host local (incluído caso não haja peers ou servidores remotos disponíveis).

O primeiro caractere exibido na tabela é um sinalizador de estado. Um estado sincronizado, representado pelo '*' como o primeiro caractere de uma entrada de servidor NTP remoto, é esperado.

Observação: Leva de 10 a 15 minutos para que esse status sincronizado ocorra se o serviço genesis com a função de líder NTP tiver sido alterado recentemente ou se a configuração do servidor NTP tiver sido modificada.

1. Para verificar o status do NTP em todos os CVMs, execute o seguinte comando de um CVM:
   nutanix@cvm$ allssh ntpq -pn
   O exemplo a seguir é um bom resultado - mostrando que o líder CVM NTP está sincronizado com um servidor NTP externo e os outros CVMs estão sincronizados com o líder CVM NTP.
   ================ 10.xx.xx.61 ===================
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   +10.xxx.xxx.21 10.xx.xx.15 4 u 654 1024 377 0,812 -1,026 0,429
   +10.xxx.xxx.22 10.xx.xx.15 4 u 997 1024 377 0,830 -0,998 0,533
   +10.xxx.xxx.10 10.xx.xx.15 4 u 409 1024 377 1.365 -1.159 5.158
   *10.xxx.xxx.11 10.xx.xx.15 4 u 579 1024 377 1.626 -1.055 0.326 <--- Sincronizado com um servidor NTP configurado 10.xx.xx.11
   127.127.1.0 .LOCL. 10 l 27h 64 0 0,000 0,000 0,000
   ================ 10.xx.xx.62 ===================
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- Sincronizado com o líder CVM NTP 10.xx.xx.61
   ================ 10.xx.xx.63 ===================
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- Sincronizado com o líder CVM NTP 10.xx.xx.61
   
   Abaixo está um exemplo de um resultado problemático. O líder CVM NTP é sincronizado apenas com seu relógio local:
   ================ 10.xx.xx.61 ===================
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   127.127.1.0 .LOCL. 10 l 27h 64 0 0.000 0.000 0.000 <--- Líder NTP CVM sincronizado apenas com seu relógio local
   ================ 10.xx.xx.62 ===================
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- Sincronizado com o líder CVM NTP 10.xx.xx.61
   ================ 10.xx.xx.63 ===================
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- Sincronizado com o líder CVM NTP 10.xx.xx.61
   
   Se o IP '127.127.1.0' estiver sendo usado, significa que os CVMs estão sincronizando apenas com o líder NTP ('127.127.1.0' é um IP localhost) e NÃO está sincronizando com nenhum servidor NTP externo no momento da verificação realizado.
2. Para verificar o status do NTP em todos os hosts/hipervisores, execute o seguinte comando de um CVM:
   nutanix@cvm$ hostssh ntpq -pn
   
   O exemplo a seguir é um bom resultado. Todos os hosts estão sincronizando com os mesmos servidores NTP.
   ============= 192.xx.xx.1 ============
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.15 218.1xx.xx.70 2 u 822 1024 377 96.679 12.968 3.105
   10.xx.xx.16 .INIT. 16 u - 1024 0 0,000 0,000 0,000
   +10.xx.xx.21 203.xx.xx.251 3 u 27 1024 377 0.609 -23.479 4.167
   ============= 192.xx.xx2 ============
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 8 1024 157 2.513 3.510 2.980
   10.xx.xx.16 .INIT. 16 u - 1024 0 0,000 0,000 0,000
   +10.xx.xx.21 203.xx.xx.251 3 u 253 1024 377 0.665 -8.794 5.203
   ============= 192.xx.xx.3 ============
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 184 1024 377 96.566 17.003 4.010
   10.xx.xx.16 .INIT. 16 u - 1024 0 0,000 0,000 0,000
   +10.xx.xx.21 203.xx.xx.251 3 u 394 1024 377 0.659 -18.181 5.601
   Se os endereços IP NTP não forem consistentemente os mesmos em todos os hosts, verifique /etc/ntp.conf para saber se eles estão usando um nome de host/FQDN que representa um pool de servidores NTP. Os pools NTP são compostos de muitas entradas DNS round-robin, portanto, no momento da inicialização, a resposta DNS fornecida a cada host quando eles iniciam o serviço NTP pode retornar um endereço IP diferente para uso como um servidor NTP.
3. Se você vir a seguinte mensagem em um host AHV ao executar o ntpq :
   Nenhum ID de associação retornado
   
   Confirme se você está executando um kernel AHV el6 executando os seguintes comandos:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# cat /etc/nutanix-release
   
   Se você estiver executando em um kernel el6, verá uma saída semelhante à abaixo:
   el6.nutanix.20170830.151
   Para corrigir esse problema temporariamente (solução alternativa), no host, reinicie o serviço ntpd usando o procedimento Reiniciando o serviço ntpd abaixo e execute novamente esta verificação NCC para confirmar.

   Para corrigir esse problema permanentemente, atualize o AOS para 5.5.8, 5.9.2, 5.10 ou posterior.

4. Se você vir a seguinte mensagem em um host ESXi ao executar ntpq , isso significa que o host ESXi/ESX não pode alcançar o servidor NTP configurado:
   Nenhum ID de associação retornado
   Confirme se a hora em todos os hosts está correta e a mesma com o comando hostssh date .

   Confirme se os IPs do servidor NTP estão configurados no host com /etc/ntp.conf.

   Confirme se a configuração do servidor DNS nos hosts está correta com o comando abaixo:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli network ip dns server list >>> To check on single host
   nutanix@cvm$ hostssh "esxcli network ip dns server list" >>> Para verificar todos os hosts
   
   Para resolver isso, corrija a configuração do servidor DNS com o seguinte comando. Como alternativa, adicione a configuração de DNS correta no Center:
   [root@Esxi:~]esxcli network ip dns server add --server=
5. Se você vir a seguinte mensagem em um host AHV ao executar o ntpq :
   Nome ou serviço desconhecido
   Esse problema pode ser causado pelo fato de o comando ntpq não conseguir resolver "localhost" em 127.0.0.1.

   Para corrigir esse problema, registre um caso com o suporte da Nutanix fornecendo os resultados e qualquer resultado da solução de problemas gerais e da configuração NTP do host atual.

6. Você pode ver o seguinte tipo de saída ao executar ntpq -pn no PCVM:
   nutanix@PCVM:~$ ntpq -pn
   remoto refid st t quando poll alcance atraso offset jitter
   ==================================================== ============================
   x10.48.147.26 .GNSS. 1 u 30 64 377 0,910 -4549,1 22,565
   x10.65.140.26 .GNSS. 1 u 58 64 377 0,251 -4527,7 15,504
   *127.127.1.0 .LOCL. 10 l 29 64 277 0,000 0,000 0,000
   nutanix@NTNX-10-66-154-101-A-PCVM:~$
   Para obter mais informações sobre o comando ntpq , consulte a página de manual do ntpq .

Revendo o conteúdo do arquivo ntp.conf

1. Revise a saída do comando ntpq -pn usando o procedimento acima.
2. Se nem todos os hosts AHV ou ESXi estiverem sincronizando o horário com o NTP, verifique os arquivos /etc/ntp.conf de todos os hosts.

   Abaixo está um exemplo de saída onde apenas 2 de 3 hosts estão sincronizando com sucesso com o NTP.

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   restringir padrão kod nomodify notrap nopeer noquery
   restringir 127.0.0.1
   servidor 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.2 ============
   restringir padrão kod nomodify notrap nopeer noquery
   restringir 127.0.0.1
   servidor 10.xx.xx.8
   driftfile /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   funileiro em pânico 0
   servidor 10.xx.xx.8
   driftfile /var/lib/ntp/drift
   arquivo de log /var/log/ntp.log
   restringir 10.8.xx máscara 255.255.255.0 nomodify notrap
   interface ignorar caractere curinga
   interface ouvir br0
   restringir 127.0.0.1
   restringir -6 ::1
   restringir padrão kod nomodify notrap nopeer noquery
   restrinja -6 padrão kod nomodify notrap nopeer noquery
   desabilitar monitor
   Na configuração de exemplo acima, os hosts 10.xx.xx.1 e 10.1xx.xx.2 estão sincronizando com sucesso com o NTP, enquanto o 10.xx.xx.3 está falhando porque está restringindo a sincronização do NTP
3. Para resolver isso, siga as etapas de solução de problemas gerais acima. Observe que os hosts AHV também são configurados junto com CVMs via Prism.
4. No caso de um problema transitório de upstream ou conectividade, reinicie o serviço ntpd usando o procedimento abaixo.
5. Aguarde de 5 a 10 minutos e execute o seguinte comando de um dos CVMs para verificar se todos os hipervisores agora estão sincronizando com o servidor NTP:
   nutanix@cvm$ hostssh ntpq -pn
6. Execute a verificação do NCC novamente.
7. Se as etapas mencionadas acima não resolverem o problema, registre um caso no Nutanix Support , fornecendo os resultados e qualquer resultado da solução de problemas gerais e da configuração NTP do cluster atual.

   Nota: No ESXi, " interface listen br0 " sendo listado em /etc/ntp.conf é conhecido por causar o problema acima. A linha deve ser removida e o serviço ntpd reiniciado.

Reiniciando o serviço ntpd/w32time

No AHV el6 ou ESXi, execute:

No AHV el7 execute:

Para verificar se a versão do AHV instalada pertence à família el6 ou el7, use o comando:

 [root@AHV]# uname -r
4.19.84-2.el7.nutanix.20190916.410.x86_64

No Hyper-V, execute:

Configurando o NTP no Hyper-V

Os hosts do Hyper-V 2016 usam o controlador de domínio como NTP. Para configurar fontes NTP externas no(s) controlador(es) de domínio do Active Directory:

1. Abra um prompt de comando no controlador de domínio com permissões administrativas.
2. Parar o serviço de tempo:
   C:\> net stop w32time
3. Defina os servidores externos da lista de peers manual:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” ”
4. Defina a conexão como confiável:
   C:\> w32tm /config /confiável:sim
5. Inicie o backup do serviço de tempo:
   C:\> net start w32time
6. Teste a configuração:
   C:\> w32tm /consulta /configuração e w32tm /consulta /status

informação adicional

• Nutanix KB 4519 - Documento original no Portal Nutanix