Kann VM nicht (mehr) starten

Erstmal vielen Dank an alle für die Unterstützung.
Ich habe den Samstag Vormittag genutzt und den Server komplett neu aufgesetzt und denke ich bin einen halben Schritt weiter, aber irgendwas fehlt noch um den zweiten Pfad zu finden.
Nach erstellen der multipath.con mit dem Inhalt von @Bu66as zeigt multipath -ll auch etwas an:
Code: 
mpatha (36000d310041e52000000000000000004) dm-5 COMPELNT,Compellent Vol
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  `- 17:0:0:1 sdb 8:16 active ready running
beim LVM steht nun für das device auch nicht mehr /dev/sdb sondern /dev/mapper/mpatha.
Allerdings sagt die Compellent dass nur ein Pfad verbunden ist:
Code: 
Nur 1 von 2 Pfaden zum Server sind aktiv.

Eine VM habe ich noch nicht erstellt, damit will ich diesmal warten, bis iSCSI mit Multipfad richtig läuft.

Bezüglich unseres produktiven Storage habe ich mit unserem Partner gesprochen und muss mich verbessern. Die zuerst angedachte Lösung hätte nur iSCSI drin gehabt. Hatten uns dann für eine (bzw. 2) Dorado entschieden, da ist alles drin. Aufgrund der Gegebenheiten und bisherigen VMWare Config wurde aber halt alles als iSCSI eingerichtet.
Der Test Storage ist halt einer der vorigen Compellent Knoten in einfachster Konfiguration mit nur einer "Faul Domain" und einem Pfad pro Controller. Auch kein Tiering oder sonstige Spielereien eingerichtet.
 
Ich glaube ich muss da nächste Woche nochmal mit freiem Kopf dran. Im Moment drehe ich mich im Kreis.
Ich habe den Host in der Compellent jetzt als "Suse Linux 15" angelegt (stand vorher auf "other multipath"), Debian oder ähnliches kennt die Compellent leider nicht, siehe Screenshot:
Linux-Complnt.jpg

Jetzt sehe ich an der CLI zumindest eine weitere Session, jedoch noch im Multipath nur einen Pfad und auch nur 1 device im lsscsi.
Wenn ich jetzt ein LVM anlege, nutzt er /dev/mapper/mpathb und der zeigt auf dm-5.

Code: 
# lsscsi
[13:0:0:0]   cd/dvd  PLDS     DVD-ROM DU-8D5LH UD5M  /dev/sr0
[14:0:0:0]   disk    ATA      DELLBOSS VD      00-0  /dev/sda
[16:0:0:0]   process Marvell  Console          1.01  -
[17:0:0:1]   disk    COMPELNT Compellent Vol   0705  /dev/sdb
Code: 
# iscsiadm -m session
tcp: [1] 172.29.1.100:3260,0 iqn.2002-03.com.compellent:5000d310041e522e (non-flash)
tcp: [2] 172.29.1.100:3260,0 iqn.2002-03.com.compellent:5000d310041e522f (non-flash)
Code: 
# multipath -ll
mpathb (36000d310041e52000000000000000005) dm-5 COMPELNT,Compellent Vol
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  `- 17:0:0:1 sdb 8:16 active ready running
Code: 
# multipath -v3
--snip--
===== paths list =====
uuid                              hcil     dev dev_t pri dm_st chk_st vend/prod/rev                dev_st
DELLBOSS_VD_e4fd9d82b3d90010      14:0:0:0 sda 8:0   1   undef undef  ATA,DELLBOSS VD,00-0         unknown
36000d310041e52000000000000000005 17:0:0:1 sdb 8:16  50  undef undef  COMPELNT,Compellent Vol,0705 unknown
633.622487 | multipath-tools v0.11.1 (01/24, 2025)
633.622498 | libdevmapper version 1.02.205
633.622604 | kernel device mapper v4.50.0
633.622619 | DM multipath kernel driver v1.15.0
633.622719 | sdb: size = 4294967296
633.622727 | sdb: vendor = COMPELNT
633.622732 | sdb: product = Compellent Vol
633.622738 | sdb: rev = 0705
633.623612 | sdb: h:b:t:l = 17:0:0:1
633.623752 | sdb: tgt_node_name = iqn.2002-03.com.compellent:5000d310041e522e
633.623768 | sdb: 0 cyl, 64 heads, 32 sectors/track, start at 0
633.623774 | sdb: vpd_vendor_id = 0 "undef" (setting: multipath internal)
633.623789 | sdb: serial = 00041e52-00000005
633.623918 | sdb: aas = 00 [active/optimized]
633.623934 | sda: udev property SCSI_IDENT_LUN_ATA whitelisted
633.623964 | wwid DELLBOSS_VD_e4fd9d82b3d90010 not in wwids file, skipping sda
633.623971 | sda: orphan path, only one path
633.623985 | sdb: udev property ID_WWN whitelisted
633.624186 | unloading tur checker
633.624209 | unloading alua prioritizer
633.624223 | unloading const prioritizer
Code: 
# ls -la /dev/mapper/mpathb
lrwxrwxrwx 1 root root 7 Dec 13 14:02 /dev/mapper/mpathb -> ../dm-5

Auf der Compellent behauptet er nun auch, dass beide Pfade zum Server verbunden sind. Kann ich (außer Kabel an der Compellent ziehen) irgendwie fest stellen ob das nun auch genutzt wird?
Bei den Anleitungen und guides, die ich finden konnte, wird dann auch immer der zweite Pfad im multipath angezeigt.

Erstmal allen ein schönes Wochenende.
 
Hi, other Multipath ist schon OK bei der Compellent.
Wie viele Pfade siehst du im PVE? (SCSI Devices /dev/SDX...)
Hast du auch auf beide Target IPs verbunden? Auch wenn die Compellent über eine Zentrale IP die anderen IPs mitteilt, funktioniert das bei Debian Systemen nicht immer Zuverlässig, daher die IPs manuell alle angeben.
 
Im PVE hatte ich bisher natürlich nur auf die virtuelle IP verbunden, Ich kenne es von den bisher genutzten Systemen so, dass darüber die anderen Pfade bekannt gemacht und automatisch verbunden werden.

Aber auch, wenn ich mehrere Verbindungen im PVE anlege zur Compellent, egal über welche IPs (ich glaube ich habe alle Kombinationen durch), ich sehe zwar 2 session in iscsiadm -m session, aber keine 2 Pfade im multipath und die 2 Pfade im iscsiadm gehen IMMER auf die virtuelle IP, egal wie ich verbunden habe in der GUI.
Aktuell habe ich einmal zum Top und einmal zum Bottom Controller verbunden. Dazu habe ich die IPs der Controller, nicht die virtuelle benutzt. Dennoch wird mir mit iscsiadm -m session angezeigt, dass beide sessions zur virtuellen IP gehen.

Ich werde noch ein wenig "herum probieren" und "stochern", aber viel Zeit ist in diesem Jahr nicht mehr (endet für mich bereits am Mittwoch Mittag) und so wirklich scheint es ohne tiefergehende iscsi+linux Kenntnisse nicht zu funktionieren. Das ist erstmal sehr Schade für uns, aber ist halt so.


Nur nebenbei, weil das ja eigentlich mein Thread Thema war: Aktuell konnte ich eine VM anlegen und auch Snapshots erstellen. Zwar nicht so wie gedacht, da schein es Einschränkungen mit TPM und snapshot-chains zu geben, aber erstmal funktioniert es generell. Die Details bzgl. Snapshots müssen wir nächstes Jahr genauer beleuchten wenn es drum geht zu schauen welche Funktionalitäten, die wir in VMWare nutzen abgedeckt werden oder abgebildet werden können.

Edit: Mit -P3 am iscsiadm sehe ich, dass die Verbindungen beide IPs kennt. virtuelle und physische. "Current Portal" zeigt immer auf die physische, "Persistent Portal" auf die virtuelle. Ohne -P3 wird wohl nur die persistent angezeigt. An der multipath -ll Ausgabe ändert sich allerdings nichts.
 
Last edited:
Martin.B. said:
Im PVE hatte ich bisher natürlich nur auf die virtuelle IP verbunden, Ich kenne es von den bisher genutzten Systemen so, dass darüber die anderen Pfade bekannt gemacht und automatisch verbunden werden.

Aber auch, wenn ich mehrere Verbindungen im PVE anlege zur Compellent, egal über welche IPs (ich glaube ich habe alle Kombinationen durch), ich sehe zwar 2 session in iscsiadm -m session, aber keine 2 Pfade im multipath und die 2 Pfade im iscsiadm gehen IMMER auf die virtuelle IP, egal wie ich verbunden habe in der GUI.
Aktuell habe ich einmal zum Top und einmal zum Bottom Controller verbunden. Dazu habe ich die IPs der Controller, nicht die virtuelle benutzt. Dennoch wird mir mit iscsiadm -m session angezeigt, dass beide sessions zur virtuellen IP gehen.
Click to expand...
Das ist ja schon mal OK.
Siehst du denn weitere Disks? Am besten mal mit lsblk abfragen.
Notfalls mit multipath - a /dev/sdX den zusätzlichen Pfad als Multipath Device hinzufügen.
Martin.B. said:
Ich werde noch ein wenig "herum probieren" und "stochern", aber viel Zeit ist in diesem Jahr nicht mehr (endet für mich bereits am Mittwoch Mittag) und so wirklich scheint es ohne tiefergehende iscsi+linux Kenntnisse nicht zu funktionieren. Das ist erstmal sehr Schade für uns, aber ist halt so.


Nur nebenbei, weil das ja eigentlich mein Thread Thema war: Aktuell konnte ich eine VM anlegen und auch Snapshots erstellen. Zwar nicht so wie gedacht, da schein es Einschränkungen mit TPM und snapshot-chains zu geben, aber erstmal funktioniert es generell. Die Details bzgl. Snapshots müssen wir nächstes Jahr genauer beleuchten wenn es drum geht zu schauen welche Funktionalitäten, die wir in VMWare nutzen abgedeckt werden oder abgebildet werden können.
Click to expand...
Snapshots werden eh überbewertet. Ich habe viele Kunden mit ihren "alten" Storages von vSphere nach PVE migriert. Alle mit shared LVM ohne Snapshots.
Wozu brauchst du denn Snapshots?
Für Backups brauchst du die Funktion auf Storagelevel nicht, da der PVE für Snapshot Backups das im qemu Layer macht, unabhängig vom Storage darunter. Für Softwareupdates macht man dann halt mal schnell ein Snapshot Backup, statt einem Snapshot auf VM Ebene. Bei einem Backup kannst du auch dateien wieder zurück holen, ohne die VM zurückrollen zu müssen und wenn du die zusätzlichen Backups etwas länger liegen lässt, ist das auch nicht so tragisch wie bei Snapshots, die weiter wachsen.
Martin.B. said:
Edit: Mit -P3 am iscsiadm sehe ich, dass die Verbindungen beide IPs kennt. virtuelle und physische. "Current Portal" zeigt immer auf die physische, "Persistent Portal" auf die virtuelle. Ohne -P3 wird wohl nur die persistent angezeigt. An der multipath -ll Ausgabe ändert sich allerdings nichts.
Click to expand...
 
  • Like
Reactions: Johannes S
Ich sehe nur sdb:
lsblk.jpg

Das mit den Snapshots müssen wir uns noch anschauen und beim Thema Backup sind wir auch noch gar nicht. Aktuell VMWare + Veeam, wobei letzteres nicht nur für VMs genutzt wird, daher wahrscheinlich auch als Backup Ziel bleiben wird. Aber alles noch nicht angesehen, daher auch keine validierte Aussage.
Nett sind Snapshot (Ketten) auf jeden Fall für Tests, da man ganz einfach zu einem bestimmten Zeitpunkt im Testverlauf zurückspringen kann. Vielleicht ist das Vorgehen unter Proxmox ein anderes oder ein anderer Weg besser und/oder schöner. Erstmal kann ich Snapshots erstellen, wenn auch leider wegen TPM und aktivierten Ketten nur in ausgeschaltetem Zustand der Maschine. Aber ich denke da schaue ich mir die Details nicht mehr dieses Jahr an.

Plan ist erstmal ein Testsystem grundlegend ans Laufen zu bekommen (da ist iscsi leider Pflicht, da die lokale Platte mit 200GB eher begrenz ist). Wenn das der Fall ist, kann unser Test ESX vielleicht da rein migriert werden, dann wird ein Host frei um auch mal einen 2 Knoten Cluster aufzubauen und weiter zu schauen. Allerdings sehe ich, wenn das erste System grundlegend läuft, erstmal wenigstens eine Community Subscription und die Suche nach einem Partner damit wir nicht ganz Kopflos weiter machen ;)
 
Martin.B. said:
Ich sehe nur sdb:
View attachment 94073

Das mit den Snapshots müssen wir uns noch anschauen und beim Thema Backup sind wir auch noch gar nicht. Aktuell VMWare + Veeam, wobei letzteres nicht nur für VMs genutzt wird, daher wahrscheinlich auch als Backup Ziel bleiben wird. Aber alles noch nicht angesehen, daher auch keine validierte Aussage.
Nett sind Snapshot (Ketten) auf jeden Fall für Tests, da man ganz einfach zu einem bestimmten Zeitpunkt im Testverlauf zurückspringen kann. Vielleicht ist das Vorgehen unter Proxmox ein anderes oder ein anderer Weg besser und/oder schöner. Erstmal kann ich Snapshots erstellen, wenn auch leider wegen TPM und aktivierten Ketten nur in ausgeschaltetem Zustand der Maschine. Aber ich denke da schaue ich mir die Details nicht mehr dieses Jahr an.

Plan ist erstmal ein Testsystem grundlegend ans Laufen zu bekommen (da ist iscsi leider Pflicht, da die lokale Platte mit 200GB eher begrenz ist). Wenn das der Fall ist, kann unser Test ESX vielleicht da rein migriert werden, dann wird ein Host frei um auch mal einen 2 Knoten Cluster aufzubauen und weiter zu schauen. Allerdings sehe ich, wenn das erste System grundlegend läuft, erstmal wenigstens eine Community Subscription und die Suche nach einem Partner damit wir nicht ganz Kopflos weiter machen ;)
Click to expand...
OK, für solche Testszenarien ist das ein valider Grund.
Du siehst nur ein Gerät/Pfad = sdb, das deutet darauf hin, dass entweder nicht mehr Targets eingeloggt sind oder die LUN nicht auf alle Pfade gemappt ist.
Die Idee mit einem erfahrenen Dienstleister ist genau richtig.
 
Vielen Dank für Dein Unterstützung und Bemühungen.
Ich werde mich im neuen Jahr weiter damit beschäftigen (müssen). Vielleicht auch direkt mit einem Experten zusammen.

Allen hier schonmal schöne Feiertage und einen angenehmen Übergang ins neue Jahr.
 
You must log in or register to reply here.
Top Bottom