Stub1004

ehm...du hast den Link auf unsere Unterhaltung gesendet...;-)

ja....

nein, aber das hatte jemand in einem Forum mal gesagt. Hmm...ich habe das Gefühl, dass der Login nicht klappt, obwohl ich bei der Security auf "none" eingestellt habe.

Ich habe versucht, die Timeout-Zeiten in der Registry zu erhöhen und erhalte nun die Fehlermeldung: "Target failed to respond in time for a login request". Kannst du damit was anfangen?

Also ich konnte mit einem Portscanner herausfinden, dass der Port offen ist. Mit Wireshark sah ich auch, dass der Server einen iSCSI Target Befehl sendet, aber nichts zurückkommt. Hmmm....

ja hab ich mir durchgelesen... Irgendwie kann er die IP x.x.x.10 auf dem Port 3260 nicht finden. Aber wenn ich die gleiche Aktion nach 45min versuche, dann gehts. Ganz komisch....

Nein, ich schliesse nur ein einzelnes Ziel an. Diese Verbindung habe ich auch schon gelöscht und neu erstellt. Leider ohne Ergebnis.

Hallo Carlito Hier die Ausgabe, was aber nicht viel sagt;-) clusterA (iSCSI): OS Type: hyper_v Member: iqn.1991-05.com.microsoft:blabla1.blabla.ch (not logged in) Member: iqn.1991-05.com.microsoft:blabla2.blabla.ch (logged in on: vif1)

Ja alles so gemacht. Der 2. Knoten des Clusters hat ja die identische Konfiguration und dort wird iSCSI sofort verbunden.

Ja die Firewall ist aus diesem Grund extra komplett abgeschaltet, damit diese nicht hineinfunken kann. Das Syslog zeigt mir die Verbindung erst nach der Wartezeit von ca. 45min an (sobald auf dem Server der Status auf "Verbunden" wechselt). Hast du eine Idee, warum er zuerst 45min lang im Leeren dreht?

Hallo Ich habe ein etwas merkwürdiges Phänomen. Ich habe einen Microsoft Failover Cluster und spriche die Clusterressourcen per iSCSI von unserem NETAPP-Filer an. Soweit klappt auch alles sehr gut. Nur beim Booten eines Knotens geht die Wiederherstellung der Verbindung nach dem Neustart sehr lange. Ca. 45min. In dieser Zeit versucht er dauernd eine Verbindung zum Netapp zu machen, was aber nie klappt. Nach 30min geht’s dann plötzlich. Im Eventlog gibts dazu folgende Einträge: Protokollname: System Quelle: MSiSCSI Datum: 12.04.2010 11:42:35 Ereignis-ID: 121 Aufgabenkategorie:Keine Ebene: Warnung Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: UxxxPROV01.ad.stub.unxxx.ch Beschreibung: Die Firewallausnahme zum Zulassen der iSNS-Clientfunktionalität (Internet Storage Name Server) ist nicht aktiviert. Die iSNS-Clientfunktionalität ist nicht verfügbar. Protokollname: System Quelle: iScsiPrt Datum: 12.04.2010 11:42:35 Ereignis-ID: 1 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: UxxxPROV01.ad.stub.unxxx.ch Beschreibung: Vom Initiator konnte keine Verbindung mit dem Ziel hergestellt werden. Die Ziel-IP-Adresse und die TCP-Anschlussnummer sind in Sicherungsdaten angegeben. Protokollname: System Quelle: iScsiPrt Datum: 12.04.2010 11:42:35 Ereignis-ID: 70 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: UxxxPROV01.ad.stub.unxxx.ch Beschreibung: Fehler beim Verarbeiten der iSCSI-Anmeldeanforderung. Die Anforderung wurde nicht wiederholt. Der Fehlerstatus wird in den Sicherungsdaten angegeben. Kann mir jemand diesbezüglich helfen? Liebe Grüsse Stub1004

Interessanter Ansatz. Welchen Virenschutz empfiehlst du den für Hyper-V Host und Guest?

Ich habs rausgefunden.... Mein geliebter TrendMicro Virenscanner machte Probleme. Ich hab ihn für die Hyper-V Verzeichnisse und Cluster Shared Storage abgeschaltet...nun klappts....

Nur hat dies ein anderes Problem generiert. Nämlich werden nun beim Importieren der virtuellen Computer in die Failover-Clusterverwaltung die Konfigurationen im Hyper-V Manager komplett gelöscht. Das heisst, ich seh dort keinen virtuellen Server mehr. Und daher lässt sich dieser dann in der Failover-Clusterverwaltung auch nicht starten... Hab ich so noch nie gesehen.... sagt das jemand was? Zumindest gibts eine Event-ID : ID: 1069 Quelle: FailoverClustering Bei der Clusterressource "Konfiguration des virtuellen Computers "xxx"" im geclusterten Dienst oder in der geclusterten Anwendung "Virtual Machine" ein Fehler aufgetreten. Zudem: Protokollname: Microsoft-Windows-Hyper-V-High-Availability-Admin Quelle: Microsoft-Windows-Hyper-V-High-Availability Datum: 25.03.2009 17:02:09 Ereignis-ID: 21203 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter: Benutzer: SYSTEM Computer: xxx Beschreibung: Fehler beim Erstellen des virtuellen Netzwerk-Switchports "'798beb4d-2925-433a-bd71-bf7d552dd1c7'. (HRESULT 0x8004100c)". Protokollname: Microsoft-Windows-Hyper-V-High-Availability-Admin Quelle: Microsoft-Windows-Hyper-V-High-Availability Datum: 25.03.2009 17:02:09 Ereignis-ID: 21117 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter: Benutzer: SYSTEM Computer: xxx Beschreibung: "Konfiguration des virtuellen Computers "xxx"": Fehler beim Erstellen der virtuellen Netzwerk-Switchports für den virtuellen Computer. Prüfen Sie die Einstellungen des virtuellen Computers. Protokollname: Microsoft-Windows-Hyper-V-High-Availability-Admin Quelle: Microsoft-Windows-Hyper-V-High-Availability Datum: 25.03.2009 17:02:09 Ereignis-ID: 21104 Aufgabenkategorie:Keine Ebene: Fehler Schlüsselwörter: Benutzer: SYSTEM Computer: xxx Beschreibung: "Konfiguration des virtuellen Computers "xxx"": Fehler beim Aufheben der Registrierung des virtuellen Computers beim Verwaltungsdienst für virtuelle Computer.

Hi Nils Ja ich habe ein iSCSI-Volume über den iSCSI Initator als Cluster-Drive angelegt. Das Snapdrive habe ich nicht. – Ich bin nun etwas weiter. Das Problem konnte ich lösen, indem ich statt einen Laufwerksbuchstaben für mein Shared Storage die GUID nahm.