Acho que você atingiu o mesmo problema como aqui .
O tempo do DomU é possivelmente acoplado ao tempo do Dom0. Você precisa dissociá-lo antes de usar ntpd ou ntpdate .
Eu tenho algumas máquinas virtuais Debian XEN e atualizei-as para wheezy (eu preciso do kernel 3.2 para um projeto). Tudo estava bem até que eu reiniciei nas máquinas.
Meu problema atual é que o ntpdate define uma data errada após a inicialização, o que tem graves implicações no aplicativo que está sendo executado nas VMs (travamentos, interrupção de dados etc. - o tempo é importante nesses servidores).
Logo após a inicialização, executei o comando ntpdate duas vezes - com a seguinte saída (confusa):
$> ntpdate server1 server2 server3
9 Apr 20:42:26 ntpdate[2371]: step time server x.x.x.x offset 83.293954 sec
$> ntpdate server1 server2 server3
9 Apr 20:40:45 ntpdate[1800]: step time server x.x.x.x offset -83.294240 sec
Após essas duas execuções, o ntpdate funciona como sempre, retornando offsets com menos de 0,0001 segundos.
Esse problema é o mesmo em todas as VMs no cluster, apenas que o deslocamento de tempo é diferente. Eu tenho visto um servidor sincronizando ~ 2800 segundos assim, então os 83 segundos na amostra acima são valores muito baixos.
Existe alguma maneira de saber por que o ntpdate está ajustando o tempo para frente e logo depois para trás de novo?!
Edit: A hora no Dom0 está correta e também sincronizada.
Acho que você atingiu o mesmo problema como aqui .
O tempo do DomU é possivelmente acoplado ao tempo do Dom0. Você precisa dissociá-lo antes de usar ntpd ou ntpdate .