qemu-guest-agent, Linux und Systemuhren im Gast bei suspendetem Host

[Marc Haber]

Hallo,

ich habe auf meinem Arbeitsplatzrechner zwei VMs installiert, mit
denen ich regelmäßig arbeite und die eigentlich immer laufen. Alle
Systeme laufen unter Debian unstable, als Virtualisierung verwende ich
KVM.

Wenn ich den Host ins Suspend-to-RAM schicke, werden die beiden VMs
über einen systemd-sleep hook suspendiert und beim aufwachen wieder
resumed. Dummerweise geht danach die Systemuhr der beiden VMs um die
Zeit falsch, die der Host suspendiert war. Ein in den VMs
installierter ntpd/chrony springt wegen der plötzlich sehr hohen
Abweichung freiwilli aus dem Fenster (ntpd) oder braucht Tage bis die
Uhrzeit sanft korrigiert wurde (chrony). Das ist nix.

Seit ich jetzt den qemu-guest-agent installiert habe, wird beim wieder
aufwachen der Systeme immerhin die emulierte Hardware-Uhr der VMs mit
der Uhr des Hosts synchronisiert, so dass ich in der VM nur noch ein
hwclock --hctosys absetzen muss, damit die Uhr wieder richtig geht.

Aber das ist halt eine manuelle Bedienhandlung in der VM.

Die "Lösung", die das Internet so bereit hat, ist ein hwclock
--hctosys in einem minütigen cronjob. Das finde ich nicht akzeptabel.

Geht das noch ein bisschen weniger unschön vielleicht? Kann ich aus
dem Host ein Signal in die VM schicken, das ich dann dort auffangen
kann um dort ein suspend/resume Script auszuführen mit dem ich die
Uhrzeit geradeziehen kann?

Grüße
Marc

[Marcel Mueller]

Post by Marc Haber
Wenn ich den Host ins Suspend-to-RAM schicke, werden die beiden VMs
über einen systemd-sleep hook suspendiert und beim aufwachen wieder
resumed. Dummerweise geht danach die Systemuhr der beiden VMs um die
Zeit falsch, die der Host suspendiert war. Ein in den VMs
installierter ntpd/chrony springt wegen der plötzlich sehr hohen
Abweichung freiwilli aus dem Fenster (ntpd) oder braucht Tage bis die
Uhrzeit sanft korrigiert wurde (chrony). Das ist nix.

ntp von den VMs runter schmeißen und Uhrzeit über den Hypervisor vom
Host injizieren ist die klassische Lösung. Aus Sicht der ganzen
Programme springt die Zeit natürlich trotzdem. Das ist unvermeidlich,
aber nicht eklatant anders, als wenn man die VMs in den Suspend
geschickt hat. Das läuft bei mir seit Jahren gut, allerdings mit VBox
statt KVM, aber das sollte aus Sicht der VMs keinen signifikanten
Unterschied machen.

Post by Marc Haber
Seit ich jetzt den qemu-guest-agent installiert habe, wird beim wieder
aufwachen der Systeme immerhin die emulierte Hardware-Uhr der VMs mit
der Uhr des Hosts synchronisiert, so dass ich in der VM nur noch ein
hwclock --hctosys absetzen muss, damit die Uhr wieder richtig geht.
Aber das ist halt eine manuelle Bedienhandlung in der VM.

Hmm, das habe ich bisher nicht gemacht. Möglicherweise ticken die
Additions doch anders.

Post by Marc Haber
Geht das noch ein bisschen weniger unschön vielleicht? Kann ich aus
dem Host ein Signal in die VM schicken, das ich dann dort auffangen
kann um dort ein suspend/resume Script auszuführen mit dem ich die
Uhrzeit geradeziehen kann?

Naja, ein remote Execute nach dem Resume wäre schon möglich.


Marcel

[Marc Haber]

Post by Marcel Mueller

Post by Marc Haber
Geht das noch ein bisschen weniger unschön vielleicht? Kann ich aus
dem Host ein Signal in die VM schicken, das ich dann dort auffangen
kann um dort ein suspend/resume Script auszuführen mit dem ich die
Uhrzeit geradeziehen kann?

Naja, ein remote Execute nach dem Resume wäre schon möglich.

ssh $VM sudo hwclock --systohc, meinst Du? Oder können die guest
additions sowas?

Grüße
Marc

[Sven Hartge]

Post by Marc Haber
Wenn ich den Host ins Suspend-to-RAM schicke, werden die beiden VMs
über einen systemd-sleep hook suspendiert und beim aufwachen wieder
resumed. Dummerweise geht danach die Systemuhr der beiden VMs um die
Zeit falsch, die der Host suspendiert war. Ein in den VMs
installierter ntpd/chrony springt wegen der plötzlich sehr hohen
Abweichung freiwilli aus dem Fenster (ntpd) oder braucht Tage bis die
Uhrzeit sanft korrigiert wurde (chrony). Das ist nix.
Seit ich jetzt den qemu-guest-agent installiert habe, wird beim wieder
aufwachen der Systeme immerhin die emulierte Hardware-Uhr der VMs mit
der Uhr des Hosts synchronisiert, so dass ich in der VM nur noch ein
hwclock --hctosys absetzen muss, damit die Uhr wieder richtig geht.

Laut /usr/share/doc/qemu-guest-agent/qemu-ga-ref.txt.gz (aus
1:3.1+dfsg-7) gibt es in der API vom Agenten "guest-suspend-disk":

,----
| This command tries to execute the scripts provided by the pm-utils
| package. If it's not available, the suspend operation will be performed
| by manually writing to a sysfs file.
|
| For the best results it's strongly recommended to have the pm-utils
| package installed in the guest.
`----

Alternativ gibt es auch "guest-exec":

,----
| Execute a command in the guest
`----

Also entweder du machst das über einen pm-utils Hook oder triggerst das
via guest-exec von außen.

S!

[Marc Haber]

Hallo Sven,

ich habe das jetzt ausprobiert.

Post by Sven Hartge
Laut /usr/share/doc/qemu-guest-agent/qemu-ga-ref.txt.gz (aus
,----
| This command tries to execute the scripts provided by the pm-utils
| package. If it's not available, the suspend operation will be performed
| by manually writing to a sysfs file.
|
| For the best results it's strongly recommended to have the pm-utils
| package installed in the guest.
`----

Ich hab's mit guest-suspend-ram probiert, da die VM nicht genug Swap
für ein suspend-to-disk der VM hat. Die VM schläft dann ein, ist aber
vom Host aus nicht wieder aufzuwecken. Das nützt mir nix ;-)

Post by Sven Hartge
,----
| Execute a command in the guest
`----
Also entweder du machst das über einen pm-utils Hook oder triggerst das
via guest-exec von außen.

Die genaue Syntax heißt

| $VIRSH qemu-agent-command $domain '{"execute": "guest-exec", "arguments": {"path": "hwclock", "arg": [ "-s" ]}}'

und scheint zu funktionieren. Allerdings wollte ich glaube ich gar
nicht wissen, dass es eine derart leichte und unauthentifizierte
Möglichkeit gibt, nahezu beliebige Kommandos _als_ _root_ in der VM
auszuführen.

Ok, der Hypervisor kann der VM theoretisch ins RAM schreiben oder man
modifiziert der VM ihr Plattenimage unterm Hintern und ist somit
sowieso root, aber das braucht IMO noch ein bisschen mehr kriminelle
Energie als ein schneller guest-exec Aufruf über das offizielle
Interface...

Damit ist mein Problem gelöst, zwar nicht schön und mit einem
riesengroßen Seiteneffekt, aber irgendwas ist ja immer.

Grüße
Marc

[Sven Hartge]

Post by Marc Haber

Post by Sven Hartge
Laut /usr/share/doc/qemu-guest-agent/qemu-ga-ref.txt.gz (aus
,----
| Execute a command in the guest
`----
Also entweder du machst das über einen pm-utils Hook oder triggerst das
via guest-exec von außen.

Die genaue Syntax heißt
| $VIRSH qemu-agent-command $domain '{"execute": "guest-exec", "arguments": {"path": "hwclock", "arg": [ "-s" ]}}'
und scheint zu funktionieren. Allerdings wollte ich glaube ich gar
nicht wissen, dass es eine derart leichte und unauthentifizierte
Möglichkeit gibt, nahezu beliebige Kommandos _als_ _root_ in der VM
auszuführen.

Jup.

VMware macht es ein wenig besser, da authentifiziert der vmguestd vorher
die Sitzung via PAM, bevor er irgendwelche Kommandos ausführt.

S!