PVE6: Probleme mit SPICE und VM-Shutdown auf selbst partitioniertem Server

Jul 25, 2019
12
0
41
Cologne
Hi @ll,

ich habe meinen Server bei Release der V6 nicht mittels des Installers, sondern mit Hilfe des normalen Debian Installers aufgesetzt und Proxmox anschließend von Hand installiert, wie es auch im Wiki beschrieben wird. Grund ist ein abweichendes Partitionslayout (Crypt-ZFS). Soweit funktioniert auch alles wie es soll.

Ich habe in der Zwischenzeit allerdings 2 kleine Probleme festgestellt.

Problem 1: SPICE
Ich kann zu keiner VM eine Verbindung via Spice aufbauen.
Auf anderen von mir betreuten Servern funktioniert das allerdings problemlos. Der einizige Unterschied ist die Art der Installation. Meinen habe ich wie oben geschrieben aufgesetzt, die anderen über den Proxmox Installer.
Auf den ersten Blick konnte ich allerdings nicht feststellen ob da irgendwas unterschiedlich installiert wurde.
Aber vielleicht fehlt ja auch irgendein Paket o.ä.

Problem 2: VM-Shutdown
Ich habe einige VMs für die es leider keinen qemu-guest-agent gibt. Diese fahren nicht herunter wenn man den Shutdown Befehl über das PVE-Webinterface gibt.
Selbiges passiert beim Shutdown des ganzen PVE-Servers. Der PVE wartet dann ewig auf das Herunterfahren der VM, was aber nicht passiert. So ist mir neulich bei einem Stromausfall die ganze Maschine abgeschmiert als der USV Akku dann irgendwann leer war.
Der Shutdown sollte doch aber eigentlich auch ohne den qemu-ga funktionieren, oder?
Auch hier vermute ich ein fehlendes oder falsch konfiguriertes Paket als Ursache.

Ich würde mich freuen wenn jemand einen Tipp hat woran die Probleme liegen könnten oder wo ich ansetzen könnte.

Danke und beste Grüße!
 
Ich habe einige VMs für die es leider keinen qemu-guest-agent gibt. Diese fahren nicht herunter wenn man den Shutdown Befehl über das PVE-Webinterface gibt.
Ist in den Optionen der VM der Guest Agent auf aktiv gesetzt? Probiere es mal diese Option zu deaktivieren. Wenn der Guest Agent in den Optionen gesetzt ist, wird bei einem Shutdown versucht dem Agent in der VM den Befehl zum herunterfahren zu geben. Wenn der Guest Agent nicht aktiviert ist wird das normale ACPI Signal zum Ausschalten geschickt, äquivalent zu einmal den Ein/Ausschalter drücken.

Problem 1: SPICE
Ich kann zu keiner VM eine Verbindung via Spice aufbauen
Hmm, das ist ein bisschen wenig Information. Wie äußert sich das Problem? Wenn du die Spice Konsole starten willst, kommt dann der Download der Configdatei?
 
Hi Aaron,

Danke für deine Antwort.

Ist in den Optionen der VM der Guest Agent auf aktiv gesetzt? Probiere es mal diese Option zu deaktivieren. Wenn der Guest Agent in den Optionen gesetzt ist, wird bei einem Shutdown versucht dem Agent in der VM den Befehl zum herunterfahren zu geben. Wenn der Guest Agent nicht aktiviert ist wird das normale ACPI Signal zum Ausschalten geschickt, äquivalent zu einmal den Ein/Ausschalter drücken.

Ich habe das jetzt nochmal ein wenig genauer untersucht. Ich habe eine eisfair VM ohne Agent (auch im PVE deaktiviert) die jegliche Reaktion auf Kommandos aus dem PVE verweigert. Egal ob Reboot, Shutdown o.ä.
Dann habe ich 2 fli4l VMs, mit aktiviertem Agent (auch im PVE) , die reagieren auch nicht. Lustigerweise reagieren sie aber auf das ACPI Signal wenn ich den Agent im PVE deaktiviere. Es scheint also nicht an PVE zu liegen. Ich werde das Problem bei den betroffenen Projekten melden.
Eine Gegenprobe mit Debian (mit Agent) und OpenWRT (ohne Agent) funktionierten problemlos.

Hmm, das ist ein bisschen wenig Information. Wie äußert sich das Problem? Wenn du die Spice Konsole starten willst, kommt dann der Download der Configdatei?

Ja, die Configdatei wird geladen und der damit verknüpfte Remote Viewer öffnet sich automatisch. Außer der Meldung "Verbinden mit Grafikserver" passiert aber nichts. Bei den anderen Servern erscheint an der Stelle nach wenigen Sekunden der Screen der VM.
Laut netstat und ps scheint der spiceproxy aber zu laufen und ich seh da auch auf den ersten Blick keinen Unterschied zu den anderen Servern.
Sicherheitshalber habe ich den Remote Viewer jetzt noch auf einem zweiten Rechner installiert. Der zeigt das gleiche Verhalten. Bei meinem eigenen Server klappt es nicht, bei den anderen geht es.
Ich habe mal die Configdateien untereinander verglichen. Abgesehen von abweichenden Daten bzgl. VM, Zertifikat, Server etc. sieht das eigentlich sehr ähnlich aus. Der einzige wirkliche Unterschied ist die Reihenfolge der Parameter.

Weitere Ideen oder Vorschläge was ich noch prüfen könnte?

Danke und Gruß!
 
Bezüglich der Spice Problematik:

Kannst du von einem der Clients nachschauen ob der Port des Spiceproxy offen ist? Evtl. funkt irgendwo eine Firewall dazwischen?

Unter Linux sollte es mit nc -zv <server> 3128 gehen.
Genauen Port und host des Proxys steht in der proxy Zeile der Config Datei für die Spicesession.
 
Hi Aaron,

Danke für deine Antwort.

Kannst du von einem der Clients nachschauen ob der Port des Spiceproxy offen ist? Evtl. funkt irgendwo eine Firewall dazwischen?

Unter Linux sollte es mit nc -zv <server> 3128 gehen.

Ich habe hier mal verschiedene Sachen getestet und wohl die Ursache finden können.
Netcat für Windows kann zwar die Option -z nicht, aber zumindest sagte es mir der Port sei offen.
Mittels telnet konnte ich zumindest eine http Fehlermeldung triggern.
Die Firewalleinstellungen zwischen den Netzen sind OK, da wird in der Hinsicht nichts unterbunden.

Dann fiel mir ein, dass es noch einen Unterschied zwischen meinem und den externen Servern gibt:
Mein Server hat auch eine IPv6 Adresse, während die anderen nur über IPv4 erreichbar sind.

Habe nun testweise an einem Client hier IPv6 deaktiviert und schon funktioniert die Verbindung einwandfrei.

Netstat auf dem PVE bestätigt denn auch das der Spice Proxy nur auf IPv4 läuft:
tcp 0 0 0.0.0.0:3128 0.0.0.0:* LISTEN 33 35704 5084/spiceproxy

Einen Eintrag für IPv6 gibt es nicht.

Was kann ich tun damit der Spice Proxy auch auf IPv6 lauscht? Und sollte das nicht eigentlich von selbst richtig konfiguriert werden wenn ich im PVE eine IPv6 Adresse konfiguriere?


Danke und Gruß!
 
Hast du in der /etc/hosts den Server selbst auch mit seiner Lokalen IPv6 Adresse hinterlegt?
Wenn noch nicht dann pveproxy und spiceproxy nach der Änderung neu starten.
 
Hi Aaron,

Hast du in der /etc/hosts den Server selbst auch mit seiner Lokalen IPv6 Adresse hinterlegt?
Wenn noch nicht dann pveproxy und spiceproxy nach der Änderung neu starten.

nein, hatte ich bisher nicht. Sollte das nicht automatisch erfolgen?

Habe es nun nachgetragen und die Dienste neu gestartet.
Nun lauschen die zwar auf IPv6, aber nicht mehr auf IPv4.
Es sollte aber doch eigentlich auf beiden lauschen, oder?

Danke und Gruß!
 
Wie schaut dein netstat output aus?
Ich habe bei mir die Situation nachgestellt und bekomme das:

Code:
tcp6       0      0 :::8006                 :::*                    LISTEN      33         1663257    6507/pveproxy       
tcp6       0      0 :::3128                 :::*                    LISTEN      33         1646746    28353/spiceproxy
Damit hören diese auch auf den IPv4 Adressen.
 
HI Aaron,

sieht bei mir genauso aus. Deswegen ging ich davon aus das er jetzt nur auf IPv6 hört.
Habe es aber eben nochmal auf einem Client mit deaktiviertem IPv6 getestet und es scheint zu funktionieren.

Trotzdem nochmal die Frage: Müsste das nicht bei der Installation automatiisch richtig gesetzt werden wenn IPv6 aktiviert ist?

Und vielleicht als Anregung: Ggf wäre es besser sich nicht auf die Angaben in der /etc/hosts zu beziehen sondern vielleicht aus der Netzwerkkonfiguration? Idealerweise mit einem kleinen Haken den man bei der Konfiguration im PVE Webinterface anhaken kann, je nachdem auf welchem Interfaces die beiden Proxys lauschen sollen? Ggf. gibt es ja Setups wo man diese Dienste an bestimmte Interfaces binden möchte, an anderen aber nicht haben will.

Nochmal vielen Dank für deine Unterstützung.
 
Schön, dass es jetzt klappt.

Das automatisch zu machen ist allerdings auch nicht ganz so einfach da es in manchen Use-Cases mitunter nicht gewollt ist, dass auf einer weiteren IP die Proxmox Dienste lauschen sollen. Siehe auch: https://bugzilla.proxmox.com/show_bug.cgi?id=422#c4
 
Ich habe das jetzt nochmal ein wenig genauer untersucht. Ich habe eine eisfair VM ohne Agent (auch im PVE deaktiviert) die jegliche Reaktion auf Kommandos aus dem PVE verweigert. Egal ob Reboot, Shutdown o.ä.
Dann habe ich 2 fli4l VMs, mit aktiviertem Agent (auch im PVE) , die reagieren auch nicht. Lustigerweise reagieren sie aber auf das ACPI Signal wenn ich den Agent im PVE deaktiviere. Es scheint also nicht an PVE zu liegen. Ich werde das Problem bei den betroffenen Projekten melden.
Eine Gegenprobe mit Debian (mit Agent) und OpenWRT (ohne Agent) funktionierten problemlos.

Hallo,

bei Eisfair einfach das Powerbutton Paket installieren und in der Konfiguration der VM den Gastagent auf deaktiviert stellen.
Läuft hier auf Eisfair64 ohne Probleme.

Viele Grüße
Detlef Paschke
 
Hi Aaron, hi Detlef,

Das automatisch zu machen ist allerdings auch nicht ganz so einfach da es in manchen Use-Cases mitunter nicht gewollt ist, dass auf einer weiteren IP die Proxmox Dienste lauschen sollen. Siehe auch: https://bugzilla.proxmox.com/show_bug.cgi?id=422#c4

der dort von Thomas L. vorgeschlagene Weg wäre auch meine Idee gewesen. Das man quasi in der Netzwerkkonfiguration angeben kann ob auf dem Interface auch die PVE Dienste lauschen sollen (oder nicht). So wäre eigentlich jedes denkbare Setup einfach umzusetzen.

bei Eisfair einfach das Powerbutton Paket installieren und in der Konfiguration der VM den Gastagent auf deaktiviert stellen.
Läuft hier auf Eisfair64 ohne Probleme.

Super, Danke für den Hinweis. Das funktioniert nun einwandfrei.

Beste Grüße!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!