Timesync no HyperV com CentOS 6.2

Eu tenho uma VM CentOS (versão 6.2) em execução no HyperV. Eu tenho serviços de integração instalados (parte da base agora) e o CentOS mostra que a fonte de relógio atual é hyperv_clocksource, no entanto, meu tempo na VM é cerca de 10 minutos mais rápido após uma semana de atividade. Meu entendimento do novo IC e da fonte de relógio plugável é que isso não deveria mais acontecer. Existe alguma configuração adicional necessária para que a fonte de relógio plugável funcione?

Eu sei que existem muitos links sobre como definir opções do kernel para o PIT e várias coisas assim, mas todos parecem pré-datar o suporte integrado ao clocksource e, pelo que entendi, não deve ser mais necessário. Nem NTPD nem adjtimex.

Edit: Estava rodando 3.2 do IC (que é fornecido com o Centos 6.2), atualizado para 3.3 hoje, a máquina ficou ativa por 1 hora e 22 minutos e o relógio já está 5 segundos mais rápido. Então, agora estou executando o IC mais recente e ainda tenho o mesmo problema.

centos hyper-v-server-2008-r2 time-synchronization

— WaldenL
fonte

Sim, o tempo é rápido, não lento. O que é ainda mais estranho, pois o problema típico do relógio da VM é a perda de tempo, não o ganho de tempo.

— WaldenL

se você executar um provedor de obtenção de ganho e ganho por Microsoft PowerShell Microsoft-Windows-Hyper-V-Integration-TimeSync | selecione mensagem | select-string "servername" você vê quaisquer erros de sincronização de tempo

— tony roth

Não importa com mensagens sobre erros de sincronização de horário, não há mensagens para esse provedor. Existem outras mensagens do Hyper-V, mas nenhuma para o TimeSync.

— WaldenL

Respostas:

Eu já tive esse problema no passado e o corrigi ajustando os switches de inicialização (notsc divider = 10) e as configurações de ntp:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-164.6.1.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VolGroup00/LogVol00 hda=noprobe hdb=noprobe notsc divider=10
    initrd /initrd-2.6.18-164.6.1.el5.img
title CentOS (2.6.18-164.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup00/LogVol00
    initrd /initrd-2.6.18-164.el5.img

Exemplo de ntp.conf:

tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
driftfile /var/lib/ntp/drift

Fonte:

Corrigindo o desvio do relógio do Linux no Hyper-V no Server 2008 R2
http://hardanswers.net/correct-clock-drift-in-centos-hyper-v

— Greg Askew
fonte

Isso pode funcionar. A postura oficial da MS é instalar / ativar os recursos de integração, incluindo sincronização de horário, e desativar todos os daemons de horário na VM (ntpd).

— Chris S

O VMWare também recomenda isso divider=10em muitas constelações de Linux.

— Nils

Desculpe pelo voto negativo, mas esses são precisamente os ajustes que não são necessários com a fonte de tempo plugável nos novos componentes de integração.

— WaldenL

Primeiro, verifique se o hyper-v está detectando os serviços de integração. A única maneira de saber como está usando o System Center Virtual Machine Manager, mas presumo que deve haver uma maneira de usar o mmc do hyper-v.

Além disso, vi isso acontecer quando a sincronização do relógio está desativada na configuração da VM. Por que o relógio corre mais rápido está além de mim. Anexei uma captura de tela da configuração vm para sua referência. insira a descrição da imagem aqui

— pescoço longo
fonte

Sim, todos os serviços estão ativados.

— WaldenL

O hyper-v informa que detectou os serviços de integração?

— longneck

Pergunta interessante, não sei como contar. O show começou no convidado, e suponho que não fariam isso se não tivessem se comunicado com o apresentador, mas não posso ter certeza. Eu não tenho scvmm, então não tenho certeza de como contar.

— #

Quando você olha para a vm no mmc, diz batimentos cardíacos ok na parte inferior? Isso indicaria que pelo menos o serviço de pulsação está se comunicando.

— longneck

Ele diz "Pulsação: OK", então parece que pelo menos o canal de comunicação está aberto.

— WaldenL

O desvio do relógio convidado do Hyper-V Linux sob carga é infelizmente bastante comum (o desvio do relógio em VMs não sincronizadas é inevitável). Veja o relógio do Linux perder 10 minutos por semana e o Hyper-V Machine desviar o tempo todo, mesmo com o NTP para outras postagens falando sobre isso. A evidência anedótica que eu vi diz o seguinte:

O relógio do host Hyper-V é usado apenas para definir o relógio do convidado Linux na inicialização dos kernels atuais (até e incluindo pelo menos os kernels da linha principal 3.16 ou os serviços de integração 3.5). Se você estiver usando esses kernels Linux, ele não importa quais as opções que você definiu no Hyper-V Manager nem isso importa que current_clocksourceé hyperv_clocksource- o seu relógio vai deriva após a inicialização e não serão corrigidos a menos que você executar um dos programas de sincronização abaixo. Há muitas informações complicadas e conflitantes, orientadas para o Windows, em torno deste tópico e, muitas vezes, termos repetidos como "fonte de tempo conectável" para entender.
ntpdé incapaz de corrigir o desvio de quantidade que pode ocorrer em um convidado Linux Hyper-V e você precisará usar sincronizações regulares de ntpdate de força bruta (ruins) ou um serviço ntp como chrony(melhor) para corrigir desvios de clock grandes.

— Anon
fonte