The tool qemu-guest-agent is not installed on your server.

  • Auf meinem vServer läuft arch linux. Installiert über das netcup image, allerdings vor Ewigkeiten. Kürzlich hat das SCP auf eine neue KVM Version hingewiesen und nach dem Neustart den Hinweis gegeben, dass der qemu-guest-agent nicht installiert sei.

    Ich habe über die arch Paketquellen die aktuelle Version installiert. Allerdings erkennt das SCP den nicht. Muss ich da noch mehr machen?


    Viele Grüße

  • Ich bekomme diese Meldung über den qemu-guest-agent auch seit einigen Tagen. Ich habe die Maschine nun mehrfach über das SCP heruntergefahren - gerade wieder - doch die Meldung bleibt. Auf meiner Maschine läuft Debian 10.3, das ich von einer hochgeladenen Original-ISO installiert habe.

  • Ich bekomme diese Meldung über den qemu-guest-agent auch seit einigen Tagen. Ich habe die Maschine nun mehrfach über das SCP heruntergefahren - gerade wieder - doch die Meldung bleibt. Auf meiner Maschine läuft Debian 10.3, das ich von einer hochgeladenen Original-ISO installiert habe.

    Du hast das Paket qemu-guest-agent aber auch installiert, ja?

    Das ist nämlich nicht von Haus aus bei Debian dabei. Kann man aber ganz normal mit apt installieren.

    RS Rentier 2019 | CX11-CEPH | CX21 | CPX11


    Wer im Netz Anstand und Respekt verliert, der ist auch im realen Leben für nichts zu gebrauchen! ;)

  • Ich habe wohl nur halb gelesen:-) Nein, tatsächlich habe ich den qemu-guest-agent nicht installiert. Mein VServer läuft schon ewig und bislang brauchte ich das nicht (meinte ich zumindest), habe die Maschine extrem selten über das SCP und fast immer aus dem Betriebssystem heraus neugestartet. Ich hab den qemu-guest-agent mal gerade nachinstalliert und die Meldung ist verschwunden.


    Vielen Dank für die Rückmeldung.

  • Mir scheint die Installation des qemu-guest-agent ein grosses Sicherheitsproblem zu sein: Hiermit eroeffne ich dem Host einen Kanal, um auf meinem Guest mehr oder weniger beliebige Kommandos auszufuehren. Das moechte ich auf keinen Fall.

  • xor Dann lass es halt weg, es zwingt Dich niemand das Programm zu installieren. Dein Gastsystem wird auch so mit den Grundfunktionen einwandfrei funktionieren. :-)


    (Ich habe das Paket aus ähnlichen Überlegungen ebenfalls nirgends installiert. Mir ist klar, dass der Host noch ganz andere Dinge anstellen könnte, aber bei dieser Schnittstelle ist mir trotzdem nicht wohl.)

  • Mir scheint die Installation des qemu-guest-agent ein grosses Sicherheitsproblem zu sein: Hiermit eroeffne ich dem Host einen Kanal, um auf meinem Guest mehr oder weniger beliebige Kommandos auszufuehren. Das moechte ich auf keinen Fall.

    Die Lösung deines Problems findest du hier. ;)


    Well - natürlich ist dem so. Aber du musst halt auch bedenken, dass die VM ohne den Guest Agent nur bedingt sauber läuft. Niemand zwingt dich zur Installation - du kannst es auch lassen, aber dann musst du damit leben, dass es zu Komplikationen kommen kann...


    Ich vertraue Netcup da soweit, dass die Hostsysteme sicher sind und dass da keiner Unfug betreibt - das muss man defacto bei jedem Hoster.

    Im Zweifel habe ich ja auch eine Alternativlösung verlinkt.

    RS Rentier 2019 | CX11-CEPH | CX21 | CPX11


    Wer im Netz Anstand und Respekt verliert, der ist auch im realen Leben für nichts zu gebrauchen! ;)

  • Der Host hat doch sowieso vollen Zugriff auf die VM. Insofern mache ich mir bei dem Tool weniger gedanken. Es geht ja primär darum, dass sich host und guest über eine spezifizierte Schnittstelle unterhalten können.


    Der Host hat damit zur Laufzeit auf die Festplatte oder kann Befehle ausführen. Sowieso hat der keinen Zugriff.

    Welche Unterhaltung zwischen Host und Gast findet da statt? Shutdown ist es nicht, dafür ist ACPI da.

  • Prinzipiell wird das Tool nicht benötigt. Qemu emuliert einen kompletten Rechner. Daher kann Shutdown etc. via "nativer" Schnittstellen erfolgen. Nun ist es aber so, dass eine VM ja z.B. angehalten werden kann, Snapshots erstellt werden oder auch Display/Maus hat. Der guest agent erlaubt eine bessere Kommunikation zwischen Host und Gast. Es geht alles auch ohne, manche Sachen aber eben besser.


    Da der Gast auf dem Host läuft, kann dieser jederzeit die VM anhalten, Befehle einbetten und dann wieder starten. Das ist natürlich aufwendig, aber denkbar. Der Guest Agent ändert also nichts daran, wie sehr ich dem Host trauen kann oder nicht.

  • Prinzipiell wird das Tool nicht benötigt. Qemu emuliert einen kompletten Rechner. Daher kann Shutdown etc. via "nativer" Schnittstellen erfolgen. Nun ist es aber so, dass eine VM ja z.B. angehalten werden kann, Snapshots erstellt werden oder auch Display/Maus hat. Der guest agent erlaubt eine bessere Kommunikation zwischen Host und Gast. Es geht alles auch ohne, manche Sachen aber eben besser.


    Da der Gast auf dem Host läuft, kann dieser jederzeit die VM anhalten, Befehle einbetten und dann wieder starten. Das ist natürlich aufwendig, aber denkbar. Der Guest Agent ändert also nichts daran, wie sehr ich dem Host trauen kann oder nicht.

    Prinzipiell alles richtig, aber es ist natürlich auch so, dass je einfacher sowas wird, desto wahrscheinlicher wird es. Will sagen: Je einfacher das Szenario wird hier mal eben den Guest zu manipulieren, desto wahrscheinlicher wird es. Code Injection ist da schon aufwändiger als wenn ich einfach 'n direkten Kanal habe, der womöglich auch noch bequem alles im Hintergrund macht.


    Letztlich Geschmackssache..

  • Live-Migration wird z.B. darüber gemacht, aber auch Speicherverwaltung ("ballooning"). Betriebssysteme wie Linux sind zunächst mal auf physikalische Hardware ausgelegt. Es gibt aber einiges, das innerhalb einer virtualisierten Umgebung besser und damit performanter gelöst werden kann, wenn es in Absprache mit dem Hypervisor geregelt werden kann. Das Stichwort heißt hier Paravirtualisierung. Deshalb gibt es den Guest-Agent, und der sollte immer aktiviert sein. Darin ein Sicherheitsrisiko zu sehen, ist ungerechtfertigte Paranoia. Der Hypervisor hat die VM sowieso in der Hand.


    Was das starten des Daemons angeht, so ist es zumindest bei Debian so, dass dieser mit Hilfe von Udev gestartet wird, sobald die dafür notwendige Schnittstelle zur Verfügung steht. Das bedeutet leider auch, dass er beendet wird, wenn man das Target mit Hilfe von `systemctl isolate` wechselt. Aber üblicherweise macht man das ja eher selten, so dass er nach der Installation des Pakets eigentlich von selbst aktiviert sein sollte.