Devo eseguire un server NTP in ogni VM?

Gli ospiti non potrebbero in qualche modo ereditare l'ora di sistema dell'host?

Sembra in qualche modo inutile eseguire lo stesso demone per ottenere gli stessi risultati sulla stessa macchina più volte, ma non ho trovato nulla di correlato al tempo durante la lettura degli articoli di KVM o Xen. La mia comprensione è che l'ospite ottiene il tempo dell'host all'avvio ma che potrebbe poi separarsi. È corretto ?

Questo è corretto. Va notato che il tempo non solo "può" andare alla deriva, ma si allontanerà a causa del fatto che gli intervalli tra gli interrupt del timer (su cui si basa spesso il cronometraggio) vengono allungati e compressi come l'hypervisor riterrebbe opportuno.

Una soluzione alternativa comunemente adottata nella maggior parte delle piattaforme di virtualizzazione (servizi di integrazione Hyper-V, strumenti VMWare) è l'esecuzione di un demone sul guest che sincronizza periodicamente gli orologi con l'host di macchine virtuali. Come notato da Hauke ​​in un commento alla tua domanda, KVM fornisce inoltre un orologio paravirtualizzato che avrebbe bisogno del rispettivo driver caricato sul SO guest per funzionare.

Cronometraggio nelle macchine virtuali VMWare (vmware.com)
Sincronizzazione dell'orologio dei guest KVM (s19n.net)

In un mondo perfetto, i tuoi ospiti VM manterrebbero il tempo perfetto, o almeno perfetto come l'host offre. Purtroppo non viviamo in un mondo perfetto.

Sulla base della mia esperienza con praticamente tutti gli hypervisor conosciuti dall'uomo, gestisco sempre un client NTP su macchine virtuali, senza eccezioni. La mia solita installazione è ntpd con l'opzione -g, o ntpdate che inizia subito prima per i vecchi sistemi, per fare il passo (che potrebbe essere molto fuori sincrono all'avvio del sistema).

KVM ha quasi la configurazione perfetta, con il suo orologio in tempo reale paravirtualizzato ; gli ospiti con il driver appropriato (almeno tutti i recenti Linux) manterranno il tempo e l'host. Ma qui le cose non vanno bene: ad esempio, l'host potrebbe non eseguire NTP, l'host potrebbe avere un fuso orario impostato errato, l'orologio dell'host potrebbe essere semplicemente sbagliato, ecc.

VMware e Hyper-V cadono nel mezzo. Ognuno ha uno strumento pensato per essere eseguito sul guest che sincronizza periodicamente l'orologio con l'host, ma, di nuovo, questo è vulnerabile a qualsiasi problema esistente con l'orologio host.

Anche gli ospiti sul mio server di prova Hyper-V hanno mostrato un comportamento strano: anche con i servizi di integrazione, l'orologio dell'ospite si spostava più velocemente di 500 ppm, impedendo a ntpd di funzionare ( considera l'orologio impazzito se va alla deriva più veloce di questo ). Ho dovuto passare questi ospiti a chrony , il che consente di adattare questo valore .

Xen è il peggiore in questo senso; non ha assolutamente alcuna sincronizzazione e l'esecuzione di NTP negli ospiti è praticamente necessaria. (Mi è stato detto che le versioni molto recenti di Xen hanno una sorta di sincronizzazione ma non ci hanno ancora lavorato personalmente.)

Le cose peggiorano se l'hypervisor host non è sotto il tuo controllo, come un cloud pubblico. Sei in balia del provider rispetto all'orologio host e se non sono diligenti nel mantenerlo sincronizzato, perdi.

Con tutto ciò, l'esecuzione di client NTP nelle macchine virtuali è praticamente necessaria se è necessario anche un orologio semi-preciso. NB: se si eseguono macchine virtuali Windows, ottenere un client NTP di terze parti che regola l'orologio continuamente; la scusa scusa per un client che viene fornito con Windows regola l'orologio solo una volta alla settimana , il che è assolutamente ridicolo.

Consiglierei di usare NTP perché è ben noto ed è in circolazione da molto tempo. La regolazione dell'orologio non è banale. NTP ha risolto questo problema.

La linea ufficiale di VMware è quella di utilizzare un meccanismo, con NTP preferito perché è più granulare e fa piccoli passi per regolare il tempo. La soluzione VMware interna compie passi più grandi. Quando corri entrambi potrebbero combattere l'un l'altro. Con la soluzione VMware interna che fa un grande passo, quindi NTP lo aggiusta e lo riprende un po '.

In pratica, tuttavia, corriamo entrambi contemporaneamente e non ho ancora riscontrato alcun problema.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status