Timesync no HyperV com o CentOS 6.2

Question

Eu tenho uma VM do 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 clocks atual é hyperv_clocksource, entretanto meu tempo na VM é de cerca de 10 minutos rápido após uma semana de tempo de atividade. Meu entendimento do novo IC e clocksource plugável é que isso não deveria acontecer mais. Existe alguma configuração adicional necessária para obter a fonte clocks plugável para "trabalhar"?

Eu sei que existem muitos links sobre como configurar as opções do kernel para o PIT e várias coisas como essa, mas todas parecem pré-datar o suporte integrado a clocksource, e pelo que eu entendi, não deveria ser mais necessário. Nem deve ntpd nem adjtimex.

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

    

Answer 1

Eu tive esse problema no passado e corrigi-lo por ajustes nas opções de inicialização (notsc divider = 10) e 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
link

    

Answer 2

Primeiro, verifique se o hyper-v está detectando os serviços de integração. A única maneira que eu sei é como usar o gerenciador de máquinas virtuais do centro do sistema, mas eu suponho 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 da VM para sua referência.

    

Answer 3

O deslocamento do relógio convidado do Hyper-V Linux sob carga é, infelizmente, bastante comum (o desvio do clock em VMs não sincronizadas é inevitável). Veja o relógio do Linux perde 10 minutos todas as semanas e Hyper-V Machine deriva todo o tempo, mesmo com NTP para outros posts falando sobre isso. Evidência anedótica que eu vi diz o seguinte:

• O relógio do host do Hyper-V é usado apenas para definir o relógio do convidado Linux na inicialização com os kernels atuais (acima para e incluindo, pelo menos, mainline 3.16 núcleos ou serviços de integração 3.5). Se você estiver usando esses kernels Linux, não importa quais opções você definiu no Hyper-V Manager nem importará que current_clocksource seja hyperv_clocksource - seu relógio irá drift after boot e não será corrigido a menos que você execute um dos programas de sincronização abaixo. Há um monte de Windows complicado e informações conflitantes ao redor este tópico e frequentemente repetiu termos como "fonte de tempo plugável" para entender.
• ntpd é incapaz de corrigir o desvio de valor que pode ocorrer em um convidado Linux Hyper-V e você terá que use sincronizações de ntpdate regulares com força bruta (ruim) ou um serviço ntp como chrony (melhor) para corrigir desvios de clock grandes.