Kann VM nicht (mehr) starten

[Martin.B.]

Wir haben seit einem knappen Monat einen Proxmox Server (v 9.1.1) zum Testen am laufen.
aktuell läuft darauf nur eine VM und die lief bisher auch problemlos. Nun wollte ich heute einen Snapshot erstellen, das schlug fehl. Bei einem Neustart der VM, konnte diese nicht mehr neu gestartet werden.
Ich versuche mal alles hier rein zu packen, von dem ich denke, dass es helfen kann, um mein Problem zu finden.
Task History der VM:

letzte Zeilen vom Snapshot Task Log:

commit-drive-efidisk0: Completing block job...
commit-drive-efidisk0: Completed successfully.
commit-drive-efidisk0: commit-job finished
delete old /dev/iscsi_dsm/vm-100-disk-0.qcow2
  Logical volume "vm-100-disk-0.qcow2" successfully removed.
  Renamed "snap_vm-100-disk-0_O2024.qcow2" to "vm-100-disk-0.qcow2" in volume group "iscsi_dsm"
blockdev replace O2024 by current
TASK ERROR: unable to create image: Could not open backing image.

Log vom VM Start Task:

TASK ERROR: start failed: qemu-img: Could not open '/dev/iscsi_dsm/snap_vm-100-disk-2_test2.qcow2': Could not open '/dev/iscsi_dsm/snap_vm-100-disk-2_test2.qcow2': No such file or directory

VM Konfig/Hardware:


Übersicht PVE:

Storage Config (datacenter/iSCSI):



Storage PVE Knoten:


Bin im Thema Proxmox relativ neu und mir fehlt hier der Ansatz, warum a) kein Snapshot gemacht werden konnte und b) die Maschine jetzt die disk nicht mehr finden und starten mag.
Haben sowohl die VM als auch den PVE Knoten inzwischen mal neu gestartet.

 

[ThoSo]

TASK ERROR: start failed: qemu-img: Could not open '/dev/iscsi_dsm/snap_vm-100-disk-2_test2.qcow2':

Das schaut so aus, als wäre dein iSCSI Device nicht "online" oder aber die Datei existiert wirklich nicht.
Ist das ein Synologic NAS das die iSCSI (iscsi_dsm) bereit stellt?
Ist genügend Speicher dort frei für den SnapShot?

 

[Martin.B.]

Das schaut so aus, als wäre dein iSCSI Device nicht "online" oder aber die Datei existiert wirklich nicht.
Ist das ein Synologic NAS das die iSCSI (iscsi_dsm) bereit stellt?
Ist genügend Speicher dort frei für den SnapShot?

Es ist eine Dell Compellent, die das bereitstellt. Das Volume hat 2 TB und ist ausschließlich dem Proxmox Knoten zugewiesen. Darauf liegt auch nur diese eine VM mit 50GB Platte (thick).
Laut der Anzeige im datacaenter sind die Dateien auch auf dem Volume vorhanden. Die Maschine lief bis zum Snapshot/Neustart vorhin auch eigentlich problemlos.

 

[Falk R.]

Irgendwie sieht die Konfiguration nicht richtig aus.
Hast du mehrere Pfade von der Compellent präsentiert?
Nutzt du Multipathing?
Wenn ich das ungenutzte iscsi Device sehe, vermute ich da grobe Misskonfiguration beim Storage. Aber da man im Screenshot nicht viel sehen kann, ist das nur eine Vermutung.

 

[Martin.B.]

Ich habe zu Testzwecken mal eine neue VM auf dem gleichen Storage angelegt. Das funktioniert.
Maschine installiert gerade Windows, wenn das durch ist, kann ich auch nochmal Snapshot Erstellung bei der VM testen.

 

[Falk R.]

Das kannst du gern lange testen, falls das Multipathing nicht oder falsch konfiguriert ist, läuft das immer erst einmal, bis zu dem Zeitpunkt wo es wieder knallt. Im schlimmsten Fall mit Datenverlust.
Daher check mal deine Konfiguration der Compellent, des Multipathing auf dem Host und prüfe ob du wirklich das Multipathdevice als Basis für dein LVM genutzt hast.

 

[Martin.B.]

Irgendwie sieht die Konfiguration nicht richtig aus.
Hast du mehrere Pfade von der Compellent präsentiert?
Nutzt du Multipathing?
Wenn ich das ungenutzte iscsi Device sehe, vermute ich da grobe Misskonfiguration beim Storage. Aber da man im Screenshot nicht viel sehen kann, ist das nur eine Vermutung.

Die Compellent ist mit 2 Pfaden angeschlossen, allerdings beide im selben Subnetz am selben Switch, also nur eine "Fault-Domain", wie das so schön bei Compellent heisst. Ist nur Testgerät, daher wird auch keine Redundanz benötigt.
PVE hat nur eine Netzwerkkarte im SAN und greift über die virtuelle IP der Compellent zu.

 

[Martin.B.]

Welche Logs/Optionen kann/soll ich noch liefern?
Bin neu bei Proxmox, das ist ein Test, der im nächsten Jahr Erkenntnis liefern soll ob das unsere VMWare Umgebung ablösen kann.
Ich bin ehrlich gesagt auch kein Linux Experte und eher GUI verwöhnt.

 

[Falk R.]

Das ganze ist natürlich nicht redundant, aber sobald du mehrere Pfade hast, musst du multipath konfigurieren. Wenn der Controller meint, den Pfad schwenken zu müssen und du nutzt nur das eine SCSI Device (ein Pfad) dann verlierst du in dem Moment den Zugriff.

 

[Falk R.]

Welche Logs/Optionen kann/soll ich noch liefern?
Bin neu bei Proxmox, das ist ein Test, der im nächsten Jahr Erkenntnis liefern soll ob das unsere VMWare Umgebung ablösen kann.
Ich bin ehrlich gesagt auch kein Linux Experte und eher GUI verwöhnt.

Da iSCSI und FC eher "veraltete" Technologien sind, wir da nicht so viel in der GUI unterstützt. Das Thema Multipathing ist wie bei jedem Linux auf der CLI zu konfigurieren. Zum testen könntest du einfach auf einen Pfad reduzieren und dann muss du nichts auf der CLI konfigurieren.
Für Produktiv sollte man es dann richtig machen und eventuell aktuellere Storagetechnologien nutzen.

 

[Martin.B.]

Da iSCSI und FC eher "veraltete" Technologien sind, wir da nicht so viel in der GUI unterstützt. Das Thema Multipathing ist wie bei jedem Linux auf der CLI zu konfigurieren. Zum testen könntest du einfach auf einen Pfad reduzieren und dann muss du nichts auf der CLI konfigurieren.
Für Produktiv sollte man es dann richtig machen und eventuell aktuellere Storagetechnologien nutzen.

Das ist Schade zu hören, da wir auch im produktiven Umfeld auf iSCSI setzen (und zumindest die nächsten 5 Jahre auch setzen werden). Da natürlich mit Redundanzen und einigen Pfaden.
Schön wäre es schon das so ans Laufen zu bekommen, dass es nahe am "echten" System ist, also entsprechend mit Multipath. Einen Pfad weg nehmen wird auch schwierig, auf dem Compellent System ist noch eine LUN die im VMWare Test Knoten eingebunden ist (mit 2 Pfaden).

Gibt es eine Einsteigerfreundliche Anleitung zu iSCSI Multipath? Idealerweise direkt Cluster geeignet, natürlich wäre der nächste Schritt ein zweiter Knoten um auch das testen zu können.

 

[Falk R.]

ISCSI funktioniert natürlich noch, aber für Multipathing wird da nichts neues entwickelt oder in die GUI kommen.
Wenn du noch 5 Jahre iSCSI fahren willst, hast du gerade etwas neues gekauft oder planst einen Kauf. Fast alle aktuellen Storages können auch z.B. NVMe over Fabric.
Wenn noch nichts gekauft wurde, kann man das ja auch vernünftig planen.

 

[Falk R.]

Multipath ist eigentlich einfach, wenn man sich mit Storage auskennt.
Ich kenne keine Anleitungen, da ich die gleichen Dinge im Linux machen muss wie schon vor 20 Jahren. Daher habe ich nie eine solche Anleitung benötigt.
Sehr viel steht im Wiki, aber nach Multipath habe ich da noch nie geschaut.

 

[Martin.B.]

ISCSI funktioniert natürlich noch, aber für Multipathing wird da nichts neues entwickelt oder in die GUI kommen.
Wenn du noch 5 Jahre iSCSI fahren willst, hast du gerade etwas neues gekauft oder planst einen Kauf. Fast alle aktuellen Storages können auch z.B. NVMe over Fabric.
Wenn noch nichts gekauft wurde, kann man das ja auch vernünftig planen.

Vernünftig geplant (und in Betrieb genommen) wurde es, aber halt für unsere jetzige VMWare Umgebung und mit den Einschränkungen was vorhandene Netzwerkleitungen zwischen den Standorten an geht. Und natürlich ist auch Kostendruck in einem Fertigungsbetrieb in DE nicht zu unterschätzen.

Ich werde schauen ob ich etwas im Wiki finde um es hin zu bekommen ohne eine komplette iSCSI/Multipath Schulung für Linux machen zu müssen. Wenn es nur über die CLI geht, dann auch darüber, das soll kein Hinderungsgrund sein.
Das ist über die GUI in VMWare und Windows halt wirklich komfortabel und die Pfade werden "von selbst" gefunden, wenn man das Portal einträgt und der iSCSI Host richtig konfiguriert ist.

 

[Falk R.]

Eigentlich muss man nur die Multipath Tools installieren und kann dann einfach mit multipath -a /dev/sdX dein SCSI Pfade adden/erlauben dass Multipath das Gerät claimen darf. Wenn du nur eine LUN hast, reicht es ein Gerät zu adden und die anderen Pfade werden automatisch erkannt und genutzt.
Soweit die Theorie. Leider haben verschiedene Hersteller von Storages auch vorgaben wie die multipath.conf konfiguriert sein muss. Oft ist das auch noch schlecht dokumentiert für Leute die sich damit nicht auskennen. Das liegt aber am jeweiligen Storagehersteller.
Wenn du z.B. eine Powerstore als Compellent ablöse hast, nutze lieber NVMe over TCP. Das kannst du parallel auf den iSCSI Ports konfigurieren beim Storage. Bei NVMe ist das ganze deutlich einfacher und multipathing im Protokoll standardisiert, so dass du da nicht nach schauen musst. Performance ist dann natürlich auch deutlich besser, bei identischer Hardware.

 

[Martin.B.]

Danke für die bisherigen Tips, ich habe mal die bisherige Konfiguration weg geworfen und versuche mich mal da dran. Irgendwie bezweifle ich aber, dass ich da heute noch zu einem Ergebnis komme.

Erstmal laufen muss es mit der Compellent. wie geschrieben versuche ich mich daran, würde bei Fragen dann aber einen neuen Thread dazu auf machen, um diesen hier nicht noch mehr zu entführen.

Das neue Storage System könnte vielleicht auch ROCE, sofern wir die Lizenz dafür kaufen. Im aktuellen Zustand wohl eher nicht.
(Netzwerk-) Hardware (inkl. Verkabelung) werden wir auch so schnell keine neue bekommen, so dass 10gbit sowieso aktuell das Limit für uns sind. Das schafft auch iscsi, sogar wenn da nur ein paar SATA SSDs hinten dran hängen würden....

 

[Falk R.]

Dann erzähl uns doch mal was ihr gekauft habt, wenn man für RoCE sogar extra bezahlen soll.
Ich persönlich finde das etwas unverschämt. Als ich vor 5 Jahren die erste Dorado mit RoCE und vSphere installiert habe, war das wenigstens dabei. Ist ja nur ein anderes Protokoll auf gleicher Hardware.

 

[Bu66as]

Hallo @Falk R.,

ergänzend dazu kurz eine "Starthilfe" für @Martin.B., damit der Test nicht an der CLI-Hürde scheitert – gerade wenn iSCSI im produktiven Umfeld gesetzt ist.

Für die Dell Compellent (SC Series) unter Debian/Proxmox reicht meist eine simple Standard-Konfiguration in der /etc/multipath.conf, damit die Pfade gebündelt werden.

1. Tools installieren:apt update && apt install multipath-tools
2. Die /etc/multipath.conf anlegen/editieren:

defaults {
    user_friendly_names yes
    find_multipaths yes
}

devices {
    device {
        vendor "COMPELNT"
        product "Compellent Vol"
        path_grouping_policy "multibus"
        path_checker "tur"
        features "0"
        hardware_handler "0"
        prio "const"
        failback "immediate"
        rr_weight "uniform"
        no_path_retry "queue"
    }
}

3. Dienst neu starten:systemctl restart multipathd

Danach sollte multipath -ll ein einzelnes Device (z.B. mpatha) mit mehreren Pfaden anzeigen. Dieses "Mapper-Device" dann im LVM als Physical Volume nutzen, nicht die einzelnen /dev/sdX.

 

[Falk R.]

Default funktioniert eigentlich immer, aber um Support zu haben oder bestimmte Verhaltensweisen der Storagecontroller abzufangen, gibts extra Empfehlungen der Hersteller.
Zum testen erst mal OK, aber wenn dann doch etwas nicht korrekt reagiert, muss man die vorgegebenen Einstellungen checken.

 

[Bu66as]

@Falk R., das ist ein wichtiger Punkt. Die oben gepostete Konfiguration entspricht daher den Dell Best Practices für die SC Series (u. a. path_checker tur und multibus), womit die spezifischen Anforderungen des Controllers abgedeckt sein sollten.

@Martin.B. Damit hättest du eine Hersteller-konforme Basis für den Test. Gib gerne Bescheid, ob das Snapshot-Verhalten damit korrigiert ist.