Le problème
J'ai le même problème et je n'ai pas trouvé de bonne solution. Voici ce que j'ai trouvé:
Le problème est qu'après la reprise, les heures d'horloge système et matérielle sur l'invité sont différentes:
root @ guest: ~ # date; hwclock
Sam.11 oct.13: 09: 38 UTC 2014
Sam.11 oct 13:10:42 2014 -0.454380 secondes
Sur l'hôte, ils conviennent:
root @ four: ~ # date; hwclock
Sam.11 oct 13:11:35 UTC 2014
Sam.11 oct 13:11:36 2014 -1.000372 secondes
La solution serait de s'exécuter hwclock --hctosys
sur l'invité après sa reprise. Cependant, je n'ai pas trouvé de moyen de le faire avec des modifications sur le système invité uniquement, car l'invité ne remarque pas qu'il est suspendu et repris.
Agent invité QEmu
Il est possible d'exécuter un logiciel appelé QEmu Guest Agent sur l'invité et de notifier à l'hôte de mettre à jour l'horloge du système invité à partir de l'horloge matérielle de l'invité. Cependant, la page mentionne que l' agent invité rend l'hôte et l'invité vulnérables aux attaques les uns des autres en raison de problèmes avec un analyseur JSON (au moins je pense que le code affecté est également exécuté sur l'hôte, je ne suis pas sûr de cela ). Quoi qu'il en soit, voici comment configurer cela:
Configurez un canal série virtio pour l'agent comme mentionné dans le wiki libvirt (voir aussi la documentation sur le format de domaine libvirt ).
Une fois le canal série disponible, installez et démarrez l'agent invité QEmu sur l'invité. (Debian:. apt-get install --no-install-recommends qemu-guest-agent
)
Déclenchez le décalage d'horloge en suspendant, en attendant et en reprenant. Exécutez ensuite la commande suivante sur l'hôte pour la corriger: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'
La page wiki qui utilise virsh qemu-agent-command
n'est pas prise en charge , mais je n'ai trouvé aucune autre commande qui fait le travail.
J'ai trouvé deux discussions sur l'automatisation dans libvirt de l'appel à la guest-set-time
reprise de la suspension:
Cependant, rien n'a été mis en œuvre pour autant que je sache.
J'ai trouvé des informations sur la façon de soumettre des commandes à l'agent invité sur le wiki de stoney-cloud.org .
J'ai également essayé de définir tickpolicy="catchup"
la configuration de la minuterie libvirt mais cela n'a pas résolu le problème.
NTP
Une alternative à l'utilisation de l'agent serait d'utiliser un démon ntp ou d'appeler ntpdate périodiquement à partir d'un travail cron. Je ne recommanderais pas ce dernier, car cela peut faire reculer le temps, ce qui peut perturber les programmes (par exemple, le serveur Dovecot IMAP n'essaie pas de gérer le temps en arrière et peut se terminer).
J'ai essayé les démons ntp suivants:
openntpd : Corrige le temps très lentement à un rythme d'environ 2 secondes toutes les 60 minutes dans mon test. Le décalage horaire était de 120 secondes. En outre, openntpd génère une erreur si le décalage horaire est trop important et, dans mon test, ne parvient pas à corriger l'heure dans ce cas. Avantages de openntpd: peut fonctionner en tant qu'utilisateur régulier dans chroot.
chrony : corrige un décalage horaire de 120 secondes en 30 minutes dans mon test. chrony peut être configuré pour fonctionner en tant qu'utilisateur normal. le support de chroot n'est pas implémenté. L'intervalle d'interrogation du serveur NTP peut être configuré pour chaque serveur NTP.
systemd-timesyncd : corrige un décalage horaire de 120 secondes en 30 secondes dans mon test. S'exécute en tant qu'utilisateur normal par défaut. Cependant, l'intervalle d'interrogation des serveurs NTP augmente jusqu'à 2048 secondes, de sorte qu'une suspension / reprise ne sera détectée que 34 minutes après la reprise dans le pire des cas. Cela ne semble pas être configurable. De plus, j'ai observé que timesyncd recule le temps, ce qui provoque les mêmes problèmes que d'appeler ntpdate dans un cron (voir ci-dessus).
chrony résout le problème. Openntpd ne convient pas car son taux de correction est trop faible et ne semble pas configurable. systemd-timesyncd ne résout pas non plus entièrement le problème, car son intervalle d'interrogation n'est pas configurable.
J'ai testé les versions Debian suivantes des démons NTP: openntpd 20080406p-10, chrony 1.30-1 et systemd 215-5 + b1.