O simples fato é que a precisão do relógio em uma VM ainda é muito ruim. Isso vem de alguns pontos, mas o mais interessante é que a deriva no tempo não é constante; o fator de desvio muda de momento para momento. O NTP é um protocolo que possui compensação de clock, mas foi projetado com um fator de desvio estático incorporado. Por exemplo, se uma máquina física perde 12 segundos a cada 30 dias, o NTP pode compensar isso e faz muito bem. Mas se essa máquina puder perder de 4 a 70 segundos a cada 30 dias, o NTP não será tão bom em acompanhar esse nível de mudança.
O que torna realmente difícil para o NTP acompanhar um ambiente de VM é que o relógio local que ele vê pode alterar seu fator de desvio ao longo de um minuto. Dependendo da frequência em que está verificando suas fontes de tempo pai, pode causar grandes alterações nos fatores de desvio e sair da sincronia com muito mais frequência. O tempo fora de sincronia se espalha por toda a organização.
O NTP para uma rede local é um protocolo de impacto relativamente baixo, com um espaço de memória muito pequeno e pode ser transferido com facilidade para outros servidores de infraestrutura de rede, como os servidores DNS e DHCP. Alguns roteadores também podem fornecer a funcionalidade NTP, portanto, convém examinar isso.
Idealmente, você deseja dois servidores separados em locais separados, cada um sincronizado com um conjunto diferente de servidores de estrato superior. Também seria uma idéia muito boa de os dois servidores de horário estarem configurados para usar o outro servidor como um 'par', o que minimizará o impacto no serviço de horário, caso uma das fontes de tempo upstream dê errado; haverá uma alteração no estrato, mas pelo menos não será relatada fora de sincronia. E, finalmente, seja gentil com seus provedores de tempo upstream e configure seus servidores para passarem muito tempo entre as pesquisas quando o tempo estiver bem estabelecido. Esse é o parâmetro 'maxpoll' na linha 'server' e é uma potência de dois em segundos entre as tentativas de sincronização.
Se você absolutamente tivesse que usar VMs para isso, eu configuraria nada menos que três desses servidores NTP. Cada um deles precisa estar em um host diferente e, se possível, em um data center diferente. Assim como o que acabei de sugerir, eles precisam de fontes de tempo diferentes e devem se espelhar. Em seguida, configure todos os seus clientes NTP para usar os três como fontes pai. Verifique se os valores de maxpoll são baixos o suficiente para nunca passar mais de uma hora e meia entre pacotes de sincronização fora da rede e 30 minutos na rede. As chances são boas de que pelo menos um dos três esteja sincronizado a qualquer momento. Para clientes que só podem conversar com um host, eles precisam apenas suportar um evento ocasionalmente fora de sincronia. No geral, a qualidade do tempo nesse cenário não seria tão exata quanto seria com os servidores físicos.
Se eu tivesse que parar, eu diria que seu tempo de consenso no ambiente de VM pura provavelmente estaria dentro de, oh, 30 a 100ms de verdade. Em um ambiente puramente físico, seu tempo de consenso provavelmente chegaria a 10 ms depois que os servidores estivessem funcionando por tempo suficiente para resolver.