Microsoft iSCSI Initiator verabschiedet sich

Hallo,

wir haben drei Windows Server (2016) mit Hyper-V Rolle.

Als Storage-System verwenden wir DataCore (PSP19) und binden den Storage (für die VMs) via iSCSI ein.
Es sind zwei DataCore-Server (aktiv-aktiv). DataCore hat ein Windows-Integration-Kit (aktuell WiK 4.1.4),
das installiert ist und sich um MPIO kümmert.
Jeder iSCSI Frontend-Port hat seinen eigenen Switch und sein eigenes Subnet.

Seit Jahren haben wir immer wieder das Problem, dass sich der Microsoft iSCSI Initiator verabschiedet.
Soll heißen: der Windows-Dienst läuft - aber das System kennt keinen Initiator mehr.

Im EventLog gibt es keine brauchen Einträge dazu. - auch DataCore konnte bisher nichts brauchbares dazu finden.

Auch nach Neustart des iSCSI-Dienstes...

sc stop MSiSCSI > nul & sc start MSiSCSI > nul & ping 127.0.0.1 -n 5 > nul & iscsicli ListInitiators

...bekommt man eine leere Liste ausgegeben:

Microsoft iSCSI-Initiator Version 10.0 Build 14393

Initiatorenliste:
Der Vorgang wurde erfolgreich beendet.

Auf einem anderen System (mit Verbindung zu denselben Targets) sieht das so aus:

Microsoft iSCSI-Initiator Version 10.0 Build 14393

Initiatorenliste:
    ROOT\ISCSIPRT\0000_0
Der Vorgang wurde erfolgreich beendet.

Auch nach einem Reboot des Servers gibt es keine Spur vom Initiator.
Wenn der Mond richtig steht, dann kehrt er - ohne Zutun - plötzlich wieder zurück.
Das System wurde auch schon neu installiert - das Verhalten bleibt gleich.

Hat das schonmal jemand erlebt? Kennt jemand evtl. die Ursache?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 672944

Url: https://administrator.de/forum/microsoft-iscsi-initiator-verabschiedet-sich-672944.html

Ausgedruckt am: 18.07.2025 um 00:07 Uhr

9 Kommentare

Neuester Kommentar

Das kann alles sein, vom nicht deaktiviertem Storm Control, über automatische Updates der Switche, bis hin zu einem Defekt oder Wackelkontakt.

Vielen Dank für die Hinweise!

Storm Control und alles andere, was mit Port-Security und QoS zu tun hat,
ist auf allen Ports deaktiviert (auch DHCP-Snooping, Packet Filter, etc.).
Einzig (M)STP ist aktiviert.

Switche, Hypervisor und SANs bekommen keine automatischen Updates.
Wackler gab es laut Switch-, Event- und DataCore-Logs keine.
Es steht auch kein Neustart nach Update-Installation aus.
Nach manueller Aktualisierung wird immer neu gestartet.

Aktuell sind die Targets wieder alle verbunden obwohl immer noch kein Initiator ausgegeben wird.

Moin,

Vorweg: hab keine Erfahrung mit iSCSI, dennoch hier mal meine Idee(n):

Sind Jumbo Frames durchgängig (nicht) aktiv? Nicht, dass da irgendwo zu viel fragmentiert werden muss...
Darüberhinaus mal die BestPractices von Datacore durchgehen: datacore.custhelp.com/app/answers/detail/a_id/1495/~/sansymphony ...

Habt ihr mal die Firmware udn Treiber sämtlicher Hardware (DataCore-Knoten, HyperV-Hosts) auf STand gebracht?
Welche Hardware kommt generell zum Einsatz? Etwas namhaftes (Dell, HPE, Lenovo/ IBM, Flutschi (

), ...) oder ein Selbstbau-Konstrukt?

Hallo,

Darüberhinaus mal die BestPractices von Datacore durchgehen:

das haben wir - mehrfach - Support-Bundles haben wir auch schon Unmengen bereitgestellt.

Sind Jumbo Frames durchgängig (nicht) aktiv?

Ja - ist Teil der Best-Practices gewesen.
Funktioniert auch auf jedem Pfad ohne Fragmentierung bis 8972 Bytes Daten (via ICMP Echo).

Habt ihr mal die Firmware und Treiber sämtlicher Hardware (DataCore-Knoten, HyperV-Hosts) auf STand gebracht?

Ja - ist Teil der Best-Practices gewesen.

Welche Hardware kommt generell zum Einsatz?

Aktuell durchgängig HPE - DL380 Gen 10 für DataCore-Server und Gen 9 für Hyper-V-Hosts.
Es sind auch nur zertifizierte Komponenten vom Hersteller in den Systemen.

Wir haben drei Hypervisor, die identisch eingerichtet sind.
Die Hypervisor nutzen dieselbe Infrastruktur (Switche).
Nur einer davon macht aktuell Probleme und der wurde testweise mit dem Original HPE-Image neu aufgesetzt.
Das neue Aufsetzen passierte zu 99% mit (Powershell-)Skripten.
(Der Aufruf des DataCore iSCSI Best Practices Script l ist Teil davon.)
Dieselben Skripte wurden auch auf den anderen Systemen verwendet.

Je nach Laune hat das System einen der vier Zustände:

Initiator weg, Verbindungen weg
Initiator da, Verbindungen weg (<= aktuell)
Initiator weg, Verbindungen da
Initiator da, Verbindungen da

Es wird auch statisch direkt via 10 GbE-Kupfer NICs verbunden - ohne iSNS, Chap, VPN/IPSec, OS-Multipath, etc.

Kann man das iSCSI - Logging / Tracing vielleicht auch irgendwie ohne Checked-Build aktivieren?

Hmm. Ok.
Wären die Aspekte auch „abgegrast“…

Ich lese 10GBit via Cu: habt ihr AutoNegotiation aktiv oder die Übertragungsrate am Switch und am HyperV fest auf 10G FullDuplex eingestellt? Oder kommen DAC-Kabel zum Einsatz?

Patchkabel vom betroffenen Host mal vorsorglich durchgetauscht?
Wäre zwar Zufall, dass da alle iSCSI-relevanten Kabel defekt sind, aber man weiß ja nie…

Ich lese 10GBit via Cu: habt ihr AutoNegotiation aktiv oder die Übertragungsrate am Switch und am HyperV fest auf 10G FullDuplex eingestellt
Patchkabel vom betroffenen Host mal vorsorglich durchgetauscht?
Wäre zwar Zufall, dass da alle iSCSI-relevanten Kabel defekt sind, aber man weiß ja nie…

Guter Hinweis! - vielen Dank!
AutoNegotiation ist aktiv - aber die NICs waren laut (OS und Switch) LOGs immer durchgängig mit 10GbE verbunden.

Wir haben gerade festgestellt, dass mit Update des WiK auf 4.1.4 die Einstellungen für
die COM+-Komponenten zurückgesetzt wurden. Deshalb gab es Einträge zu VSS im EventLog.
Vielleicht ist das Verhalten ein Seiteneffekt. Das jetzt jetzt geändert - Neustart steht allerdings noch aus:

$usr = '...'  
$pw = '...'  

$targetApp = "DataCore VSS Hardware Provider"   
$comAdmin = New-Object -comobject COMAdmin.COMAdminCatalog
$apps = $comAdmin.GetCollection("Applications")  
$apps.Populate();
$app = $apps | Where-Object {$_.Name -eq $targetApp}
$comAdmin.ShutdownApplication($targetApp)
$app.Value("Identity") = $usr  
$app.Value("Password") = $pw  
$apps.SaveChanges()
$comAdmin.StartApplication($targetApp)

$rk = 'HKLM:\SOFTWARE\Classes\CLSID\{DC5D6DBC-F1FF-4218-BEA2-1623A2BC58E8}'  
$acl = Get-Acl $rk
:: $acl.Access
$idRef = [System.Security.Principal.NTAccount]("ALLE ANWENDUNGSPAKETE")  
$regRights = [System.Security.AccessControl.RegistryRights]::FullControl
$inhFlags = [System.Security.AccessControl.InheritanceFlags]::None
$prFlags = [System.Security.AccessControl.PropagationFlags]::None
$acType = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule ($idRef, $regRights, $inhFlags, $prFlags, $acType)
$acl.AddAccessRule($rule)
$acl | Set-Acl -Path $rk
:: $acl = Get-Acl $rk
:: $acl.Access

Seit den Änderung (gefolgt von einem Neustart) gab es keine Probleme mehr.
Es scheint also ausschließlich an den Berechtigungen des DataCore VSS Hardware Providers gelegen zu haben.