Sul mio host sto usando libvirt e un ospite KVM. Quando l'host si sta spegnendo, libvirt sospende l'ospite. Quando l'host si avvia, libvirt riprende il guest. Il problema è che se l'ospite viene sospeso e ripreso dopo 24 ore, ad esempio, il tempo dell'ospite è di 24 ore in passato.

Ho pensato che forse il problema riguarda l'origine clock, ma è già impostato su "kvm-clock".

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc hpet acpi_pm 

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

Il problema

Ho lo stesso problema e non ho trovato una buona soluzione. Ecco cosa ho trovato:

Il problema è che dopo il ripristino, i tempi di clock dell'hardware e del sistema sul guest sono diversi:

root @ guest: ~ # date; hwclock
Sab 11 ott 13:09:38 UTC 2014
Sab 11 ott 13:10:42 2014-0,454380 secondi

Sull'host, concordano:

root @ four: ~ # date; hwclock
Sab 11 ott 13:11:35 UTC 2014
Sab 11 ott 13:11:36 2014 -1.000372 secondi

La soluzione sarebbe eseguire hwclock --hctosyssul guest dopo che è stato ripreso. Tuttavia, non ho trovato un modo per farlo solo con modifiche sul sistema guest, poiché l'ospite non nota che è sospeso e ripreso.

QEmu Guest Agent

Esiste la possibilità di eseguire un software chiamato QEmu Guest Agent sul guest e di avvisare dall'host di aggiornare l'orologio del sistema guest dall'orologio hardware del guest. Tuttavia, la pagina menziona che l' agente guest rende l'host e l'ospite vulnerabili agli attacchi reciproci a causa di problemi con un parser JSON (almeno credo che il codice interessato sia eseguito anche sull'host, non ne sono sicuro ). Ad ogni modo, ecco come configurarlo:

1. Imposta un canale seriale virtio per l'agente come menzionato nel wiki libvirt (vedi anche la documentazione sul formato del dominio libvirt ).

2. Una volta disponibile il canale seriale, installare e avviare QEmu Guest Agent sul guest. (Debian:. apt-get install --no-install-recommends qemu-guest-agent)

3. Attiva l'offset dell'orologio sospendendo, aspettando e riprendendo. Quindi esegui il seguente comando sull'host per correggerlo: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'La pagina wiki che utilizza nonvirsh qemu-agent-command è supportata , ma non ho trovato nessun altro comando che funzioni.

Ho trovato due discussioni sull'automazione all'interno di libvirt della chiamata a guest-set-timesu riprendi dalla sospensione:

• http://thread.gmane.org/gmane.comp.emulators.libvirt/92431 (febbraio 2014)
• http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051 (settembre 2014)

Tuttavia, nulla è stato ancora implementato per quanto ho potuto vedere.

Ho trovato informazioni su come inviare comandi all'agente guest sul wiki di stoney-cloud.org .

Ho anche provato a impostare tickpolicy="catchup"la configurazione del timer libvirt ma questo non ha risolto il problema.

NTP

Un'alternativa all'utilizzo dell'agente sarebbe quella di usare un demone ntp o di chiamare periodicamente ntpdate da un cron job. Non consiglierei quest'ultimo, poiché può far tornare indietro il tempo, il che può confondere i programmi (ad esempio, il server IMAP Dovecot non cerca di gestire il tempo che va indietro e può terminare).

Ho provato i seguenti demoni ntp:

• openntpd : corregge il tempo molto lentamente a una velocità di circa 2 secondi per 60 minuti nel mio test. La differenza oraria era di 120 secondi. Inoltre, openntpd genera un errore se la differenza di tempo è troppo grande e, nel mio test, in questo caso non riesce a correggere completamente l'ora. Vantaggi di openntpd: può essere eseguito come utente normale in chroot.

• chrony : nel mio test corregge un time offset di 120 secondi in 30 minuti. chrony può essere configurato per essere eseguito come utente normale. il supporto chroot non è implementato. L'intervallo di polling del server NTP può essere configurato per ciascun server NTP.

• systemd-timesyncd : nel mio test corregge un time offset di 120 secondi in 30 secondi. Viene eseguito come utente normale per impostazione predefinita. Tuttavia, l'intervallo di polling dei server NTP aumenta fino a 2048 secondi, in modo che una sospensione / ripresa non venga rilevata fino a 34 minuti dopo la ripresa nel caso peggiore. Questo non sembra essere configurabile. Inoltre, ho osservato timesyncd fare un passo indietro nel tempo, il che causa gli stessi problemi di chiamare ntpdate in un cron (vedi sopra).

chrony risolve il problema. Openntpd non è adatto perché il suo tasso di correzione è troppo basso e non sembra essere configurabile. systemd-timesyncd non risolve del tutto il problema, poiché il suo intervallo di polling non è configurabile.

Ho testato le seguenti versioni Debian dei demoni NTP: openntpd 20080406p-10, chrony 1.30-1 e systemd 215-5 + b1.

Molte operazioni dell'host di virtualizzazione sul guest possono provocare una pausa - ripresa. Ciò avrà un effetto negativo sull'orologio di sistema sul guest. Ad esempio, la clonazione di una macchina virtuale provoca una pausa durante la clonazione. L'orologio degli ospiti dopo è alle spalle. Per fare in modo che NTP sincronizzi l'orologio, è necessario riavviare il guest, non una buona soluzione in tutti i casi. In alternativa, potresti semplicemente riavviare ntpd nel guest, ma neanche questo è ottimale. Idealmente, è necessario che sia disponibile un evento (ripresa da VM) che è possibile utilizzare facoltativamente per questo tipo di correzione per il guest.

Dopo aver trascorso un po 'di tempo a cercare questo, ho deciso di utilizzare l'orologio host direttamente come riferimento per l'orologio del sistema operativo guest CentOS 7.

Invece di eseguire ntpd nel guest, ho deciso che ogni 15 minuti avrei impostato, tramite crontab, l'orologio del sistema guest dal clock hardware del guest. L'orologio hardware del guest riflette l'ora dell'host di virtualizzazione che è controllata tramite ntpd in esecuzione sull'host di virtualizzazione. Questo mi fornisce un tempo affidabile nel sistema operativo guest. Nel peggiore dei casi, l'orologio potrebbe essere spento per un massimo di 15 minuti prima che venga sincronizzato all'ora corretta dopo aver ripreso l'ospite.

# crontab -e

0,15,30,45 * * * * /sbin/hwclock --hctosys

Sarebbe molto meglio avere un evento disponibile presso l'ospite che avvierebbe una sincronizzazione temporale al momento della ripresa dell'ospite, ma apparentemente non è disponibile. L'approccio crontab è una soluzione alternativa in quanto effettua una chiamata hwclock ogni 15 minuti. Fa il lavoro, ma non elegantemente come vorrei.

kvm-clock sincronizza l'ora dell'ospite per ospitare l'ora all'avvio dell'ospite . È necessario utilizzare il client ntp nel guest e arrestare / avviare invece di utilizzare suspend / resume.

libvirt supporta la sincronizzazione dell'ora degli ospiti dal 2015 . Su Debian Stretch e successivamente cerca l'opzione SYNC_TIMEin /etc/default/libvirt-guests:

# If non-zero, try to sync guest time on domain resume. Be aware, that
# this requires guest agent with support for time synchronization
# running in the guest. For instance, qemu-ga doesn't support guest time
# synchronization on Windows guests, but Linux ones. By default, this
# functionality is turned off.
#SYNC_TIME=1

Puoi testare la sincronizzazione temporale dall'interno del sistema host con:

virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'

Questo comando dovrebbe tornare {"return":{}}in caso di successo.

Uso un modo simile per sincronizzare il tempo dopo la sospensione / ripresa della VM, ma penso che sia meglio provare a indovinare, che dovrebbe sincronizzarsi nella giusta direzione ed è più lungo della differenza breve, che potrebbe essere risolto da NTPD.

https://gist.github.com/jhrcz/7138803

PS. Il nuovo log delle modifiche di centos 6.7 dice che questo potrebbe essere fatto automaticamente con la sola sorgente di clock kvm-clock.