tempo sistema mantém zerando a 4 horas em evento passado pensamento fuso horário é correta eo tempo está sendo sincronizados

2

Eu tenho um servidor Windows 2008 - 32 bits - em execução em um ambiente ESX.

Posso sincronizar manualmente a hora para um servidor de horário (time.microsoft.com, tick.gatech.edu ou qualquer outro servidor de horário) e a hora é configurada corretamente e exibida no relógio da bandeja do sistema. Também estou definindo o fuso horário corretamente para o horário do leste - Ajustado para o horário de verão.

Tudo parece bom neste momento.

No entanto, se eu reiniciar o sistema, o relógio do sistema será definido 4 horas antes. (ou seja, 16:00 horas em tempo real torna-se 12:00 no sistema).

Eu então tenho que forçar um tempo resync ou mannual definir o tempo para a hora correta. Minutos não são afetados - mas o tempo é definido exatamente 4 horas antes.

Isso está me enlouquecendo e estou procurando uma solução para isso. Infelizmente, várias tarefas importantes neste servidor são sensíveis ao tempo e isso está causando um problema real.

Eu já verifiquei que o VMtools não está configurado para sincronizar o relógio com o servidor ESX.

Obrigado por qualquer ajuda.

    
por Richard West 29.10.2010 / 22:39

3 respostas

2

@ScottWarren - Você está certo de que é a solução a longo prazo. No entanto, eu queria ter tempo para explicar por que isso aconteceu em primeiro lugar, para que outros usuários saibam por que isso acontece com eles.

Lembre-se: em VM Tools no cliente, selecionei que o cliente NÃO deveria sincronizar a hora do sistema com o ESX Host, no entanto, isso ainda estava ocorrendo.

A razão para isso é explicada em VMware KB 1189 .

Basicamente, há duas ocasiões em que uma VM ignorará sua solicitação para não ter uma sincronização de convidado com o host ESX:

  • Quando você suspende uma máquina virtual, na próxima vez em que retomar essa máquina virtual, ela sincroniza a hora para ajustá-la ao host.
  • O tempo é ressincronizado quando você migra a máquina virtual usando o VMotion, pega um ponto de verificação, restaura em um ponto de verificação, encolhe o disco virtual ou reinicia o serviço de ferramentas na máquina virtual ( incluindo a reinicialização da máquina virtual ).

É por isso que este sistema estava sendo redefinido a cada vez que é reinicializado. É estranho que a VMware ignore a solicitação do usuário para que isso não aconteça, mas agora eu tenho uma compreensão completa de como e por que isso estava acontecendo.

Neste caso, eu estava vendo a diferença de horário por causa de uma nova instalação do ESXi 4.1 em nosso ambiente. O novo servidor não tinha configurações de NTP e, portanto, fornecia informações de horário incorretas aos clientes.

    
por 31.10.2010 / 21:43
4

Tivemos o problema exato na semana passada. Acontece que a hora do host ESX realmente importa, já que é com isso que o servidor começa quando é redefinido (o que descobrimos depois que o Microsoft reinicia o patch). O que era realmente suspeito era que ele continuava sendo redefinido para a mesma escala de tempo após as reinicializações. No seu caso, é agora-4h, no nosso caso, foi Now-42days. Depois que resolvemos o tempo do host ESX, ele parou de fazer isso e a sincronização normal de tempo do Windows conseguiu mantê-lo no prazo.

    
por 29.10.2010 / 22:52
0

Eu também tive o mesmo problema há alguns dias. A conclusão é que o tempo do ESX precisa estar correto ou o BIOS (apresentado pelo host ESX) aparece com um tempo incorreto após cada reinicialização, o que atrapalha a hora no Windows. Se o delta de tempo for muito grande, o w32tm falhará ao sincronizar.

A melhor aposta é corrigir a hora no host ESX, mas se você não conseguir fazer isso, poderá sempre alterar a correção máxima de fase ( artigo do MS KB ) para um número maior (o padrão é apenas 5 minutos), o que permitirá que você sincronize sob a condição de que você está ... embora haja possíveis implicações negativas aqui se você definir esse para um número alto (leia as notas no artigo kb para exemplos)

    
por 29.10.2010 / 23:29