Estou executando um convidado RHEL 5 (64 bits) no Microsoft Hyper-V.
Eu sempre tive problemas com o relógio ficando à frente de si mesmo, o que consegui resolver anteriormente adicionando
divider = 10 clocksource = acpi_pm
para o kernel params em /boot/grub/menu.lst e configurando o ntpd.
Isso funcionou com o kernel 2.6.18-194.3.1.el5, entretanto, já que a atualização de segurança para 2.6.18-194.8.1.el5 ntp não será mais sincronizada.
Aqui está a saída do ntpq -pn com 2.6.18-194.3.1.el5
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.189.54.33 203.35.83.242 2 u 5 64 377 17.311 -51.753 63.074
*202.83.64.2 203.35.83.242 2 u 7 64 377 19.625 -104.46 27.096
+202.60.94.11 203.12.160.2 3 u 62 64 377 34.398 -121.42 26.216
127.127.1.0 .LOCL. 10 l 11 64 377 0.000 0.000 0.001
E com o 2.6.18-194.8.1.el5
$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
192.189.54.33 192.189.54.17 3 u 28 64 17 17.075 -9505.7 5518.42
192.189.54.17 203.35.83.242 2 u 28 64 17 17.389 -9669.1 5596.65
202.60.94.11 203.12.160.2 3 u 33 64 17 33.192 -142.84 9016.50
*127.127.1.0 .LOCL. 10 l 31 64 17 0.000 0.000 0.001
Estou sem ideias. Eu tentei alguns outros parâmetros do kernel, como
notsc divider = 10
Mas ainda os mesmos resultados.
Alguma sugestão sobre o que mais pode funcionar?
Acredito que acabei de encontrar a resposta. Eu precisava adicionar notsc mas também manter divider = 10 e clocksource = acpi_pm também.
A entrada em /boot/grub/menu.lst agora se parece com isso e o clique parece estar sincronizando novamente:
kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet notsc divider=10 clocksource=acpi_pm
Os serviços de integração estão configurados para definir o relógio? Em caso afirmativo, você tentou desativá-lo?