Kein Zugriff auf Konsole einer Virtuellen Maschine

chralt

Well-Known Member
Aug 26, 2020
52
4
48
68
Hallo Zusammen,

ich habe ein weiteres Problem an dem ich schon länger herumdoktere.

Nach dem Upgrade von Proxmox-VE 8.4.17 auf 9.1.14 habe ich keinen Zugriff mehr auf zwei von mehreren VMen, leider, wie as immer so ist, auf den wichtigsten nämlich den MariaDB-Server.

Weder per ssh noch über die PVE-Web-Oberfläche sind diese VMen zu erreichen. Bei ssh gibt es die Meldung "ssh: connect to host 192.168.x.x port 22: No route to host". Bei der Konsole der PVE-Oberflache wird mir das login angezeigt, bei Eingabe des Nutzers und anschließender Entertaste springe zwar der Cursor in die nächste Zeile, aber "Passwort" wird nicht angezeigt und das wars dann auch.

Die VM des MariaDB-Serverss iat 100GB groß, allerdings viel zu groß, die hälfte würde reichen.
Es gibt eine weitere VM, sie ist 32GB groß, läuft aber noch auf einer PVE 8.1.14, ist also noch nnicht migriert..

Un weil ich gerade dabei bin: obwohl ich Proxmox seit geraumer Zeit verwende gibt es (mind.) 1 Sache die ich noch nicht kapiert habe: auf der Proxmoxoberfläche werden in der linken Spalte "local (pve)" sowie "local-lvm (pve) angezeigt. auf Beiden werden unterschiedliche Inhalte angezeigt, so weit so gut.

Auf Proxmox 9 wird unter local "94.78% (95.60 GB von 100.86 GB), für local-lvm "67.12% (243.85 GB von 363.31 GB) ausgegeben.
Was ich nicht weiss wie diese zusammenhängen. Auf local ist der Rest-speicher minimal, unter local-lvm sind noch > 100GB frei. Ob und wie kann ich von Speicher von local-lvm auf local sagen wir mal rüber schieben? Auf der alten Proxmox Maschine sind die Füllgrade bei 70 bzw. 77% wobei auch hier unter locsl-lvm wesentlich mehr Speicher zur Verfügung steht.

Ob das Problem mit den nicht ansprechbaren VMen mit der Speicherproblematik zu tun hat kann ich nicht beurteilen.

Gruß und Danke im Vorraus

chralt
 
Wird dir im PVE zu deiner VM eine IP angezeigt und passt die auch zu deinem SSH Connect?
Die VMs mal neu gestartet mit Blick auf die Konsole?
Browser Einstellungen mal zurückgesetzt (Cache) ?
Irgendwelche Blocker aktiv?
Sind deine Netzwerk(e) UP?
Hast das Passwort mal blind eingegeben?
Die dümmste Frage der Welt - wie schaut's mit Backup der (so wichtigen) VMs aus?
...
 
  • Like
Reactions: micneu
Erst einmal Danke!

Ich fange mal mit der letzten Frage an: ja, ich würde aber gerne die "Original" VM wieder ans flimmern bekommen, außerdem kann ich damit ja was lernen.
Die IP wird angezeigt uns passt zum ssh
Cache nicht zurückgesetzt, allerdings habe ich es mit mehreren Rechnern versucht: Laptop (könnten auch 2 gewesen sein), Tablet, Mobiltelefon
Blocker sind aktiv, alle anderen VMen funktionieren allerdings auf beiden PVE problemlos.
Netzwerke UP ???
Das jeweilige Passwort habe ich mehrfach blind eingegeben, wird angezeigt bis wieder "MariaDB login:"angezeigt wird
 
Teile bitte mal ein bischen mehr infos zur hardware und zu config der vm.
Ist die per ping von irgendeiner maschine erreichbar?
Evtl. Auch mal die allerneusten updates für den pve einspielen.
sind auf dem PVE eigene netzwerke eingerichtet?
Die ip der vm ist statisch oder dhcp?

Helperscripte eingesetzt?
Evtl mal ein paar hardcopies beifügen.
 
Last edited:
Ich habe hinter die Fragen die jeweiligen Antworten geschrieben, ich denke das ist ok so.:cool:

Hardware der VM
Speicher min 512MB max. 2,05 GB
Prozessoren;L 4 (1 sockets, 4 cores) [vm64]
BIOS: Standaŕteinstellung (SeaBOIS)
Anzeige: Stamdardeinstellung
Maschinentyp: tamdardeinstellung (i1440fx)
SCSI Controller: VirtlO SCSI
CD/DVD Laufwerk (ide2): none,Media=cdrom
Laufwerk (scsi0) local.vm:vm102.disk-0,size=100GB
Netzwerkkarte (net0): virtio:xx:xx:xx ED:27,bridge=vmbr0,firewall=1
Abgesehen von den Speichergrößen und USB (sofern vorhanden, bei der Betroffenen sind keine angeschlossen) habe ich bei den anderen Eigenschaften nichts verändert, sie sind auch identisch mit denen der anderen VMen.

Ist die per ping von irgendeiner Maschine erreichbar? - Nein, aber die anderen VMen sind erreichbar

Evtl. Auch mal die allerneusten updates für den pve einspielen. - leider nicht möglich:
Warning: More space needed than available: 1161 MB > 0 B, installation may fail
Error: You don't have enough free space in /var/cache/apt/archives/.
Ich habe den Ordner /var/cache/apt/archives/ gerade von allem was 2024 und älter ist auf eine USB-Platte verschoben. Dann habe ich 2 oder 3 VMen - nach deren Sicherung - gelöscht, was leider nicht zu zusärtzlichem Speicher geführt hat.keinen Speicherplatz. Der alktuelle Speicherplatz verteilt sich so:
root@pve:/# du -h --max-depth=1
12G ./var
12K ./.config
4.0K ./srv
16K ./lost+found
3.9M ./run
6.2G ./usr
0 ./sys
du: cannot access './proc/3049890/task/3049890/fd/3': No such file or directory
du: cannot access './proc/3049890/task/3049890/fdinfo/3': No such file or directory
du: cannot access './proc/3049890/fd/4': No such file or directory
du: cannot access './proc/3049890/fdinfo/4': No such file or directory
du: cannot access './proc/3049918': No such file or directory
du: cannot access './proc/3049920': No such file or directory
0 ./proc
413M ./boot
0 ./tmp
240K ./home
du: cannot read directory './mnt/backups': Permission denied
64G ./mnt
7.5G ./root
43M ./dev
37M ./etc
4.0K ./opt
8.0K ./media
90G .
/var sieht dann so aus:
root@pve:/# du -h --max-depth=1
12G ./var
12K ./.config
4.0K ./srv
16K ./lost+found
3.9M ./run
6.2G ./usr
0 ./sys
du: cannot access './proc/3049890/task/3049890/fd/3': No such file or directory
du: cannot access './proc/3049890/task/3049890/fdinfo/3': No such file or directory
du: cannot access './proc/3049890/fd/4': No such file or directory
du: cannot access './proc/3049890/fdinfo/4': No such file or directory
du: cannot access './proc/3049918': No such file or directory
du: cannot access './proc/3049920': No such file or directory
0 ./proc
413M ./boot
0 ./tmp
240K ./home
du: cannot read directory './mnt/backups': Permission denied
64G ./mnt
7.5G ./root
43M ./dev
37M ./etc
4.0K ./opt
8.0K ./media
90G .

Sind auf dem PVE eigene netzwerke eingerichtet? - Nein, ich weiß auch nicht wie das geht:(

Die ip der vm ist statisch oder dhcp? - die VMen sind alle auf DHCP, aber der Router (FB) gibt ihnen immer die jeweils selbe IPv4

Helperscripte eingesetzt? - Nein
 
Last edited:
Dein root-Verzeichnis ist zu voll. Deshalb kein update möglich, Schaffe dort Platz indem du erstmal Platz schaffst. Schaue in der Web-GUI, was auf local liegt. Falls dort nichts zu finden ist, lösche alte Kernelversionen. falls das immer noch nicht reicht, installiere ncdu um Speicherfresser zu lokalisieren.

Die FB ist kein Ausbund an Zuverlässigkeit bei der IP-Vergabe. Probiere mal nmap <IP> um offene Ports angezeigt zu bekommen.

Du sprichst auch wirklich über VMs und keine LXCs?
 
  • Like
Reactions: ThoSo
Da hast du schon ein massives Problem, welches du wie bereits erwähnt beseitigen MUSST.

/dev/mapper/pve-root ext4 94G 90G 0 100% /

Schicke doch mal ein beherztes
ls -l /boot/
 
Last edited:
apt-get auto-remove && apt-get auto-clean hat gerade mal 577MB gebracht, das wird wohl kaum reichen.

Mit @impack komme ich nicht weiter: entweder kommt nix, oder die Meldung
Com and Not Fonds
Hab verschiedene Möglichkeiten (welcher User, mit oder ohne die eckigen Klammern, kleines oder großes "i"
 
apt-get auto-remove && apt-get auto-clean hat gerade mal 577MB gebracht, das wird wohl kaum reichen.

Mit @impack komme ich nicht weiter: entweder kommt nix, oder die Meldung

Hab verschiedene Möglichkeiten (welcher User, mit oder ohne die eckigen Klammern, kleines oder großes "i"
Das bezog sich auf den Auftrag vom Kollegen @Impact ... weiter oben ;-)


Dein Ordner mnt belegt 64GB?
Kannst das mal prüfen was da alles lagert?
Wenn du direkt nichts finden solltest, hebe dem SMB Mount temporär einmal auf - evtl wird das "überlagert".
 
Last edited:
Wie @ThoSo sagte, müllt dir /mnt gerne dein / zu, wenn ein PVE dorthin Daten schreibt, während irgendwas nicht gemountet ist. Also dort alles unmounten und nochmal prüfen, wieviel Speicher der Ordner belegt. Sollte kaum messbar sein...

P.S.: solange dort noch irgenwas korrekt gemountet ist, verhageln diese natürlich deine
du -hs /mnt Werte. Also vorher wirklich alles mit umount /mnt/Ordnername deaktivieren.
 
Last edited:
Da hast du schon ein massives Problem, welches du wie bereits erwähnt beseitigen MUSST.

/dev/mapper/pve-root ext4 94G 90G 0 100% /

Schicke doch mal ein beherztes
ls -l /boot/
:oops::cool:root@pve:/mnt# ls -l /boot/

total 323932

-rw-r--r-- 1 root root 237252 Nov 16 2020 config-5.4.73-1-pve
-rw-r--r-- 1 root root 280345 Jul 26 2024 config-6.5.13-6-pve
-rw-r--r-- 1 root root 287122 Mar 13 09:15 config-6.8.12-20-pve
-rw-r--r-- 1 root root 308342 May 15 09:32 config-7.0.2-4-pve
drwxr-xr-x 3 root root 4096 Jan 1 1970 efi
drwxr-xr-x 6 root root 4096 Jun 6 17:40 grub
-rw-r--r-- 1 root root 44713567 Oct 13 2023 initrd.img-5.4.73-1-pve
-rw-r--r-- 1 root root 60575277 Aug 1 2024 initrd.img-6.5.13-6-pve
-rw-r--r-- 1 root root 61443934 Mar 15 16:35 initrd.img-6.8.12-20-pve
-rw-r--r-- 1 root root 76004618 May 23 12:13 initrd.img-7.0.2-4-pve
-rw-r--r-- 1 root root 151020 Nov 17 2024 memtest86+ia32.bin
-rw-r--r-- 1 root root 152064 Nov 17 2024 memtest86+ia32.efi
-rw-r--r-- 1 root root 155992 Nov 17 2024 memtest86+x64.bin
-rw-r--r-- 1 root root 157184 Nov 17 2024 memtest86+x64.efi
drwxr-xr-x 2 root root 4096 May 23 12:05 pve
-rw-r--r-- 1 root root 4717516 Nov 16 2020 System.map-5.4.73-1-pve
-rw-r--r-- 1 root root 7978698 Jul 26 2024 System.map-6.5.13-6-pve
-rw-r--r-- 1 root root 8379565 Mar 13 09:15 System.map-6.8.12-20-pve
-rw-r--r-- 1 root root 10452992 May 15 09:32 System.map-7.0.2-4-pve
 
Last edited:
Wie @ThoSo sagte, müllt dir /mnt gerne dein / zu, wenn ein PVE dorthin Daten schreibt, während irgendwas nicht gemountet ist. Also dort alles unmounten und nochmal prüfen, wieviel Speicher der Ordner belegt. Sollte kaum messbar sein...

P.S.: solange dort noch irgenwas korrekt gemountet ist, verhageln diese natürlich deine
du -hs /mnt Werte. Also vorher wirklich alles mit umount /mnt/Ordnername deaktivieren.
Genau das ist passiert, da sind Backups der VMen mit insgesamt 64GB

Darum werde ich mich aber erst Morgen kümmern.

Erstmal herzlichen Dank für eure Hilfe!

Ich werde berichten!
 
  • Like
Reactions: ThoSo
Genau das ist passiert, da sind Backups der VMen mit insgesamt 64GB

Darum werde ich mich aber erst Morgen kümmern.

Erstmal herzlichen Dank für eure Hilfe!

Ich werde berichten!
Schön, dass du den Problembären offenbar identifiziert hast.
Was du auf alle Fälle per apt remove entfernen kannst, ist alles was -5. enthält.
Mit Mut zur Lücke auch alles, was -6. enthält. Danach kannst du natürlich nicht mehr auf einen 6er-Kernel zurückfallen.

Das leidige mount-Thema kann man übrigens mit chattr +i /mnt/ordnername entschärfen.
Soll sogar auch irgenwie per WebGUI-Parameter funktionieren.
 
Last edited:
Schön, dass du den Problembären offenbar identifiziert hast.
Was du auf alle Fälle per apt remove entfernen kannst, ist alles was -5. enthält.
Mit Mut zur Lücke auch alles, was -6. enthält. Danach kannst du natürlich nicht mehr auf einen 6er-Kernel zurückfallen.

Das leidige mount-Thema kann man übrigens mit chattr +i /mnt/ordnername entschärfen.
Soll sogar auch irgenwie per WebGUI-Parameter funktionieren.
Ich biete Dir noch dieses Bash-Script an, welche alle Installationseste des Debian Sysstem enfernt.
Code:
for f in $(dpkg -l | grep "rc  " | cut -d " " -f 3); do echo $f; apt purge -y $f; done
Das löscht mehr, als man erwartet.
 
Last edited:
Ich biete Dir noch dieses Bash-Script an, welche alle Installationseste des Debian Sysstem enfernt.
Code:
for f in $(dpkg -l | grep "rc  " | cut -d " " -f 3); do echo $f; sudo apt purge -y $f; done
Das löscht mehr, als man erwartet.
Schönes Ding für tabula rasa.
 
Last edited: