Eu tenho um par de RHEL 6 virtualizado em execução em um host RHEV. O host e as VMs têm um tempo de atividade de 1 ano.
Apenas nos últimos dois dias, eles raramente começaram a enviar essas mensagens do kernel em horários aleatórios
kernel: Clocksource tsc unstable (delta = -17179878652 ns). Enable clocksource failover by adding clocksource_failover kernel parameter.
Ótimo: seguirei o conselho. O estranho é que eu não estou usando o tsc como uma clocksource
[~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
Estudando a documentação do framework clocksource, eu criei mais perguntas do que respostas.
Primeiro, por que o kernel está reclamando de uma clocksource que o sistema não deveria usar? O ciclo do kernel está de qualquer maneira através de todos os clocksources disponíveis, talvez? Se sim, para quê?
Tanto quanto eu sei, a mensagem significa que a origem de clocks atual é separada da watchdog clocksource em mais de WATCHDOG_THRESHOLD , mas qual é a origem de clocks do watchdog atual? Não pode ser kvm-clock, já que geralmente tem CLOCK_SOURCE_MUST_VERIFY set. Existe uma maneira de exibi-lo em tempo de execução?
Eu entendo que o tsc não é considerado preciso com CPUs modernas devido aos recursos de limitação / economia de energia, mas /proc/cpuinfo informa que os processadores vistos pela VM possuem o constant_tsc sinalizador. Então, eu diria que o tsc também pode fornecer um tempo bastante confiável. Essa bandeira é um "bypass" para a CPU real subjacente ou é apenas uma emulada, executando seu próprio contador? No primeiro caso, eu poderia especular que o agendador do host mudou o processo da VM para um núcleo diferente, tendo um contador derivado. Isso poderia fazer sentido?