O simples fato é que a precisão do clock em uma VM ainda é muito ruim. Isso vem de alguns pontos, mas o mais importante é que o tempo não é constante; o fator de deriva muda de momento para momento. O NTP é um protocolo que possui uma compensação de clock embutida, mas foi projetado com um fator de desvio estático embutido. Por exemplo, se uma máquina física perder 12 segundos a cada 30 dias, o NTP pode compensar isso e o faz muito bem. Mas se essa máquina pode perder de 4 a 70 segundos a cada 30 dias, o NTP não é tão bom em acompanhar esse nível de mudança.
O que torna muito difícil manter o NTP em um ambiente de VM é que o relógio local que ele vê pode mudar seu fator de desvio ao longo de um minuto. Dependendo da frequência em que está verificando suas origens de tempo pai, isso pode causar grandes alterações no fator de desvio e fazer com que ele saia de sincronia com muito mais frequência. Tempo de sincronização fora de sincronia em toda a sua organização.
O NTP para uma rede local é um protocolo de impacto relativamente baixo, com um tamanho de memória muito pequeno, e pode ser usado com facilidade em outros servidores de infraestrutura de rede, como os servidores DNS e DHCP. Alguns roteadores também podem fornecer a funcionalidade NTP, então você pode querer investigar isso.
O ideal é que você queira dois servidores separados em locais separados, cada um sincronizado com um conjunto diferente de servidores de estrato superior. Também seria uma boa idéia de ambos os servidores de tempo terem sido configurados para usar o outro servidor como um 'peer', o que minimizará o impacto no tempo de serviço, caso um dos fontes de tempo upstream dê errado; haverá uma mudança de estrato, mas pelo menos não será reportado fora de sincronia. E, finalmente, seja gentil com seus provedores de tempo de upstream e configure seus servidores para passar muito tempo entre as pesquisas, uma vez que o tempo esteja bem estabelecido. Este é o parâmetro 'maxpoll' na linha 'server' e é uma potência de dois em segundos entre as tentativas de sincronização.
Se você 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. Tal como com o que acabei de sugerir, eles precisam de diferentes fontes de tempo e devem olhar um para o outro. Em seguida, configure todos os seus clientes NTP para usar todos os três como fontes pai. Verifique se os valores de seu maxpoll estão baixos o suficiente para nunca ultrapassar uma hora e meia entre os pacotes de sincronização fora da rede e 30 minutos na rede. As chances são boas, pelo menos, um dos três estará em sincronia a qualquer momento. Para os clientes que só podem conversar com um host de tempo, eles apenas terão que aturar um evento ocasional fora de sincronia. No geral, a qualidade do tempo neste cenário não seria tão exata quanto seria com os servidores físicos.
Se eu tivesse que jogar bola, eu diria que seu tempo de consenso no ambiente de VM pura provavelmente estaria dentro de 30 a 100 ms de verdade. Em um ambiente puramente físico, seu tempo de consenso provavelmente estaria dentro de 10ms, uma vez que os servidores de tempo estivessem ativos o suficiente para que o tempo se resolvesse.