KVM, Gastzeit kann nach Upgrade OS15.1 -> 15.2 nicht gesetzt werden
Hallo, seit dem Upgrade mittels zyyper dup von OS15.1 auf OS15.2 kann ich auf meinen laufenden Gastsystemen die Zeit nicht mehr setzen. Das hat vorher immer zuverlässig funktioniert. Aktuell: Kernel 5.3.18-lp152.41-default qemu-kvm-4.2.1-lp152.9.3.1.x86_64 Seit dem Upgrade gibt es diese Fehlermeldung: ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock (held by agent=remoteDispatchDomainSetTime) Im Netz bin ich nicht zielführend fündig geworden. Es gibt dazu einen Bugzilla-Report (zwar wegen kaputtem Netzwerk, aber das Zeitproblem ist dort auch beschrieben). Das Zeitproblem tritt auch auf einem anderen Host nachvollziehbar auf. https://bugzilla.opensuse.org/show_bug.cgi?id=1174607 Hat jemand eine Idee dazu? Viele Grüße, Klaus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 02.10.20 um 16:26 schrieb funedv@gmx.de:
Hallo,
seit dem Upgrade mittels zyyper dup von OS15.1 auf OS15.2 kann ich auf meinen laufenden Gastsystemen die Zeit nicht mehr setzen. Das hat vorher immer zuverlässig funktioniert.
Aktuell: Kernel 5.3.18-lp152.41-default qemu-kvm-4.2.1-lp152.9.3.1.x86_64
Seit dem Upgrade gibt es diese Fehlermeldung: ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock (held by agent=remoteDispatchDomainSetTime)
Im Netz bin ich nicht zielführend fündig geworden. Es gibt dazu einen Bugzilla-Report (zwar wegen kaputtem Netzwerk, aber das Zeitproblem ist dort auch beschrieben). Das Zeitproblem tritt auch auf einem anderen Host nachvollziehbar auf. https://bugzilla.opensuse.org/show_bug.cgi?id=1174607
Hat jemand eine Idee dazu?
Hier(tm) laufen der gleiche Kernel und die gleiche Version des qemu-kvm. Der Gast ist allerdings ein Leap 15.2. Damit lässt sich dein o.g. Befehl ohne Fehlermeldung ausführen. Läuft der qemu-Agent auf dem Gast? Muss der evtl. aktualisiert werden? Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.10.20 um 09:56 schrieb Bernd Nachtigall:
Am 02.10.20 um 16:26 schrieb funedv@gmx.de:
Hallo,
seit dem Upgrade mittels zyyper dup von OS15.1 auf OS15.2 kann ich auf meinen laufenden Gastsystemen die Zeit nicht mehr setzen. Das hat vorher immer zuverlässig funktioniert.
Aktuell: Kernel 5.3.18-lp152.41-default qemu-kvm-4.2.1-lp152.9.3.1.x86_64
Seit dem Upgrade gibt es diese Fehlermeldung: ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock (held by agent=remoteDispatchDomainSetTime)
Im Netz bin ich nicht zielführend fündig geworden. Es gibt dazu einen Bugzilla-Report (zwar wegen kaputtem Netzwerk, aber das Zeitproblem ist dort auch beschrieben). Das Zeitproblem tritt auch auf einem anderen Host nachvollziehbar auf. https://bugzilla.opensuse.org/show_bug.cgi?id=1174607
Hat jemand eine Idee dazu?
Hier(tm) laufen der gleiche Kernel und die gleiche Version des qemu-kvm. Der Gast ist allerdings ein Leap 15.2. Damit lässt sich dein o.g. Befehl ohne Fehlermeldung ausführen.
Läuft der qemu-Agent auf dem Gast? Muss der evtl. aktualisiert werden?
Sorry, Kommando zurück ... Es war der falsche Gast. (SLES statt openSUSE) Es könnte am neuen guest-agent liegen. 3.1.1.1 funktioniert. 4.2.1 tut es nicht. Wenn du es brauchst ist wohl eine Meldung im bugzilla fällig. Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.10.20 um 09:56 schrieb Bernd Nachtigall:
Am 02.10.20 um 16:26 schrieb funedv@gmx.de:
Hallo,
seit dem Upgrade mittels zyyper dup von OS15.1 auf OS15.2 kann ich auf meinen laufenden Gastsystemen die Zeit nicht mehr setzen. Das hat vorher immer zuverlässig funktioniert.
Aktuell: Kernel 5.3.18-lp152.41-default qemu-kvm-4.2.1-lp152.9.3.1.x86_64
Seit dem Upgrade gibt es diese Fehlermeldung: ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock (held by agent=remoteDispatchDomainSetTime)
Im Netz bin ich nicht zielführend fündig geworden. Es gibt dazu einen Bugzilla-Report (zwar wegen kaputtem Netzwerk, aber das Zeitproblem ist dort auch beschrieben). Das Zeitproblem tritt auch auf einem anderen Host nachvollziehbar auf. https://bugzilla.opensuse.org/show_bug.cgi?id=1174607
Hat jemand eine Idee dazu?
Hier(tm) laufen der gleiche Kernel und die gleiche Version des qemu-kvm. Der Gast ist allerdings ein Leap 15.2. Damit lässt sich dein o.g. Befehl ohne Fehlermeldung ausführen.
Läuft der qemu-Agent auf dem Gast? Muss der evtl. aktualisiert werden?
Bernd
Hallo Bernd, das Problem tritt bei allen Gästen auf: OS15.2, Windows 10, Windows 7. Außerdem bei einem zweiten Host, bei dem ich versuchsweise KVM frisch installiert habe und einen OS15.2-Gast eingerichtet habe. Guest-Agent Host 1: Windows 10 + Windows 7: läuft OS15.2: läuft nicht und lässt sich nicht starten Host 2: noch nicht geprüft. Ich muss nachschauen, ob es für die Windows Agenten irgendwelche Updates gibt und klären, warum der qemu-Agent auf dem OS15.2-Gast nicht zum Laufen zu bringen ist. Vielen Dank für den Hinweis auf die Agenten. Melde mich, sobald ich mehr weiß. Viele Grüße, Klaus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo,
ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock held by agent=remoteDispatchDomainSetTime
das klingt für mich, als ob der Agent da eben aktiv wäre und die Funktion nicht freigibt. Bei mir sieht es so aus, dass ich den Befehl nach dem Start einer VM einmal ausführen kann, bei einem weiteren Versuch erhalte ich den genannten Fehler. Daher die Annahme, ob bei dir dieser Befehl bereits ausgeführt wurde und die Synchronisierung ohnehin aktiv ist. Oder ist die Zeit in der VM daneben? Grüße Richard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.10.20 um 13:43 schrieb Richard Hafenscher:
Hallo,
ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock held by agent=remoteDispatchDomainSetTime
das klingt für mich, als ob der Agent da eben aktiv wäre und die Funktion nicht freigibt.
Bei mir sieht es so aus, dass ich den Befehl nach dem Start einer VM einmal ausführen kann, bei einem weiteren Versuch erhalte ich den genannten Fehler. Daher die Annahme, ob bei dir dieser Befehl bereits ausgeführt wurde und die Synchronisierung ohnehin aktiv ist. Oder ist die Zeit in der VM daneben?
Grüße Richard
Hallo, dieses Verhalten (genau einmal funktioniert das Setzen der Gastzeit, danach nicht mehr) konnte ich auf Host 2 bei der Inbetriebnahme des dortigen Gastsystems beobachten. In den Opensuse Gastsystemen gibt es einen Dienst qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service, der lässt sich nicht starten und hat den vendor preset disabled (und war das auch). Log: qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service - QEMU Guest Agent Loaded: loaded (/usr/lib/systemd/system/qemu-ga@.service; enabled; vendor preset: disabled) Active: inactive (dead) Eine versuchsweise Einstellung "Bei Systemstart" ergibt keine Änderung. Die Zeit in den VMs ist z.B. daneben, wenn ich die Gäste speichere, den Host in den Energiesparmodus versetze, wieder aufwecke und die Gäste wieder starte. Dann stimmt bei den Gästen die Systemzeit nicht. Die Systemzeit der Gäste stimmt immer, wenn ich den Host neu starte. Das brachte mich auf die Idee, bei laufendem Host nach dem Speichern der Gäste rclibvirtd neu zu starten, dann bekommen die Gäste die richtige Zeit. Viele Grüße, Klaus
Am 03.10.20 um 13:43 schrieb Richard Hafenscher:
Hallo,
ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock held by agent=remoteDispatchDomainSetTime
das klingt für mich, als ob der Agent da eben aktiv wäre und die Funktion nicht freigibt.
Bei mir sieht es so aus, dass ich den Befehl nach dem Start einer VM einmal ausführen kann, bei einem weiteren Versuch erhalte ich den genannten Fehler. Daher die Annahme, ob bei dir dieser Befehl bereits ausgeführt wurde und die Synchronisierung ohnehin aktiv ist. Oder ist die Zeit in der VM daneben?
Grüße Richard
Hallo,
dieses Verhalten (genau einmal funktioniert das Setzen der Gastzeit, danach nicht mehr) konnte ich auf Host 2 bei der Inbetriebnahme des dortigen Gastsystems beobachten.
In den Opensuse Gastsystemen gibt es einen Dienst qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service, der lässt sich nicht starten und hat den vendor preset disabled (und war das auch). Log: qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service - QEMU Guest Agent Loaded: loaded (/usr/lib/systemd/system/qemu-ga@.service; enabled; vendor preset: disabled) Active: inactive (dead)
Eine versuchsweise Einstellung "Bei Systemstart" ergibt keine Änderung.
Die Zeit in den VMs ist z.B. daneben, wenn ich die Gäste speichere, den Host in den Energiesparmodus versetze, wieder aufwecke und die Gäste wieder starte. Dann stimmt bei den Gästen die Systemzeit nicht.
Die Systemzeit der Gäste stimmt immer, wenn ich den Host neu starte. Das brachte mich auf die Idee, bei laufendem Host nach dem Speichern der Gäste rclibvirtd neu zu starten, dann bekommen die Gäste die richtige Zeit.
Viele Grüße, Klaus
Hi, wenn qemu-guest nicht läuft, wird das Setzen der Zeit fehlschlagen, ist klar. Blöde Frage, aber der VM hast du schon ein Serial-Gerät und einen org.qemu.guest_agent.0 Channel hinzugefügt? Dass das nicht gegeben ist, ist nämlich die einzige mir bekannte Ursache dafür, dass sich der Dienst nicht starten lässt. Grüße Richard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.10.20 um 22:35 schrieb Richard Hafenscher:
Am 03.10.20 um 13:43 schrieb Richard Hafenscher:
Hallo,
ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock held by agent=remoteDispatchDomainSetTime
das klingt für mich, als ob der Agent da eben aktiv wäre und die Funktion nicht freigibt.
Bei mir sieht es so aus, dass ich den Befehl nach dem Start einer VM einmal ausführen kann, bei einem weiteren Versuch erhalte ich den genannten Fehler. Daher die Annahme, ob bei dir dieser Befehl bereits ausgeführt wurde und die Synchronisierung ohnehin aktiv ist. Oder ist die Zeit in der VM daneben?
Grüße Richard
Hallo,
dieses Verhalten (genau einmal funktioniert das Setzen der Gastzeit, danach nicht mehr) konnte ich auf Host 2 bei der Inbetriebnahme des dortigen Gastsystems beobachten.
In den Opensuse Gastsystemen gibt es einen Dienst qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service, der lässt sich nicht starten und hat den vendor preset disabled (und war das auch). Log: qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service - QEMU Guest Agent Loaded: loaded (/usr/lib/systemd/system/qemu-ga@.service; enabled; vendor preset: disabled) Active: inactive (dead)
Eine versuchsweise Einstellung "Bei Systemstart" ergibt keine Änderung.
Die Zeit in den VMs ist z.B. daneben, wenn ich die Gäste speichere, den Host in den Energiesparmodus versetze, wieder aufwecke und die Gäste wieder starte. Dann stimmt bei den Gästen die Systemzeit nicht.
Die Systemzeit der Gäste stimmt immer, wenn ich den Host neu starte. Das brachte mich auf die Idee, bei laufendem Host nach dem Speichern der Gäste rclibvirtd neu zu starten, dann bekommen die Gäste die richtige Zeit.
Viele Grüße, Klaus
Hi,
wenn qemu-guest nicht läuft, wird das Setzen der Zeit fehlschlagen, ist klar.
Blöde Frage, aber der VM hast du schon ein Serial-Gerät und einen org.qemu.guest_agent.0 Channel hinzugefügt? Beides bei allen guests vorhanden.
Dass das nicht gegeben ist, ist nämlich die einzige mir bekannte Ursache dafür, dass sich der Dienst nicht starten lässt.
Grüße Richard
Hm. Der Fehler ist nach dem Upgrade des host von 15.1 -> 15.2 bei allen guests aufgetreten, definitiv ohne dass es Änderungen bei den guests gab. Also muss es irgendwie mit dem Upgrade des host rsp. einer Veränderung dort zusammenhängen. Viele Grüße, Klaus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.10.20 um 10:11 schrieb funedv@gmx.de:
Am 03.10.20 um 22:35 schrieb Richard Hafenscher:
Am 03.10.20 um 13:43 schrieb Richard Hafenscher:
Hallo,
ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock held by agent=remoteDispatchDomainSetTime
das klingt für mich, als ob der Agent da eben aktiv wäre und die Funktion nicht freigibt.
Bei mir sieht es so aus, dass ich den Befehl nach dem Start einer VM einmal ausführen kann, bei einem weiteren Versuch erhalte ich den genannten Fehler. Daher die Annahme, ob bei dir dieser Befehl bereits ausgeführt wurde und die Synchronisierung ohnehin aktiv ist. Oder ist die Zeit in der VM daneben?
Grüße Richard
Hallo,
dieses Verhalten (genau einmal funktioniert das Setzen der Gastzeit, danach nicht mehr) konnte ich auf Host 2 bei der Inbetriebnahme des dortigen Gastsystems beobachten.
In den Opensuse Gastsystemen gibt es einen Dienst qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service, der lässt sich nicht starten und hat den vendor preset disabled (und war das auch). Log: qemu-ga@virtiox2dports-org.qemu.guest_agent.0.service - QEMU Guest Agent Loaded: loaded (/usr/lib/systemd/system/qemu-ga@.service; enabled; vendor preset: disabled) Active: inactive (dead)
Eine versuchsweise Einstellung "Bei Systemstart" ergibt keine Änderung.
Die Zeit in den VMs ist z.B. daneben, wenn ich die Gäste speichere, den Host in den Energiesparmodus versetze, wieder aufwecke und die Gäste wieder starte. Dann stimmt bei den Gästen die Systemzeit nicht.
Die Systemzeit der Gäste stimmt immer, wenn ich den Host neu starte. Das brachte mich auf die Idee, bei laufendem Host nach dem Speichern der Gäste rclibvirtd neu zu starten, dann bekommen die Gäste die richtige Zeit.
Viele Grüße, Klaus
Hi,
wenn qemu-guest nicht läuft, wird das Setzen der Zeit fehlschlagen, ist klar.
Blöde Frage, aber der VM hast du schon ein Serial-Gerät und einen org.qemu.guest_agent.0 Channel hinzugefügt? Beides bei allen guests vorhanden.
Dass das nicht gegeben ist, ist nämlich die einzige mir bekannte Ursache dafür, dass sich der Dienst nicht starten lässt.
Grüße Richard
Hm. Der Fehler ist nach dem Upgrade des host von 15.1 -> 15.2 bei allen guests aufgetreten, definitiv ohne dass es Änderungen bei den guests gab. Also muss es irgendwie mit dem Upgrade des host rsp. einer Veränderung dort zusammenhängen.
Viele Grüße, Klaus
Hi, einige Dinge konnte ich herausfinden. Starte ich rclibvirtd neu, oder auch den Host, dann geht nach dem erneuten Verbinden mit quemu folgendes: virsh start openSUSE-Leap15.0 virsh domtime openSUSE-Leap15.0 --now Und nun kommt es: Der letzte Befehl funktioniert immer genau ein Mal. Bei jedem weiteren Versuch gibt es dann den erwähnten Fehler. Bei OS 15.1 konnte man diesen letzten Befehl zum Setzen der Gastzeit beliebig oft durchführen, ohne dass rclibvirtd neu gestartet werden musste. Vielen Dank fürs Mitdenken, Klaus
participants (4)
-
Bernd Nachtigall -
funedv＠gmx.de -
Klaus Schneider-Grosch
-
Richard Hafenscher