Posts Tagged: Bugs

Probleme mit der Namensauflösung unter Windows Server 2012

Folgendes Verhalten: Hyper-V Hosts unter Windows Server 2012 in einem Failovercluster. Die virtuellen Maschinen funktionieren einwandfrei, ebenso der Failovercluster. Einzig über das Management-Interface kommt man nicht mehr per Hostnamen über RDP drauf. Ein kurzer Ping zeigt, dass der Name der Hosts nicht aufgelöst werden kann. Aha. Per IP-Adresse kann man sich einwandfrei darauf verbinden. Aha.

To make a long story short: Ein abgesetztes netstat -anob brachte erstaunliches zu Tage. Es sind so gut wie alle Port bis 65535 vom Prozess Dnscache belegt!

Die Recherche in den üblichen Quellen des WWW blieb erstaunlich ergebnislos. Einzig ein Thread in den Microsoft-Foren war interessant. Port Exhaustion with Dnscache. Und ein etwas älterere Blog-Eintrag des Directory Services Team mit dem schönen Titel Port Exhaustion and You (or, why the Netstat tool is your friend).

Schneller Fix um wieder eine funktionstüchtige Namensauflösung bereitzustellen:

  1. Ermitteln der ProcessId des dnscache-Prozesses mittels tasklist /SVC|find /i "dns"
  2. Beenden des Prozesses TASKKILL /PID ProcessID /F (ist ein svchost; ja, es laufen wahrscheinlich weitere Dienste unter diesen service host, welche jedoch automatisch wieder gestartet werden).
  3. Dienst DNS-Client auf dem Server neu starten.
  4. Sollte von einem weiteren Client der Name noch nicht wieder aufgelöst werden, auf dem Client ein ipconfig /flushdns setzen, dann klappt’s.

Den Workaround lt. Thread konnte ich noch nicht verifizieren. Ein etwas offiziellerer Workaround ist mir lieber (obwohl scheinbar vom Premier Support). Zumal die Suche nach den zwei Parametern für den Dnscache ebenso wenig liefert. Jedenfalls sollte man unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters zwei neue DWORDs MulticastResponderFlags und MulticastSenderFlags anlegen. Wert jeweils 1.

Problem mit SDDDSM & SVC & 2012 Failover Cluster

Heute über ein kurioses Problem gestolpert. Folgende Konfiguration: IBM Storage Volume Controller (SVC) und Windows Server 2012 Failover Cluster. Zwei Windows Server 2012 Nodes im Cluster. Aufgabe war, ein Volume zu vergrößern. Also im SVC die Platte vergrößert (ja, es ist noch keine dünn provisionierte). OK. Nächster und letzter Schritt die Platte im Windows zu erweitern. Commandline auf, diskpart gestartet und … nichts! Diskpart bleibt beim Starten hängen, die Ereignisanzeige geht mit den Events 17 und 18 der Quelle mpio über.

Fehler    27.08.2013 14:40:13    mpio    16
Failover auf "\Device\MPIODisk4".

Warnung    27.08.2013 14:40:13    mpio    17
"\Device\MPIODisk4" befindet sich zurzeit in einem heruntergestuften Zustand. Bei mindestens einem Pfad ist ein Fehler aufgetreten, der Prozess wurde trotzdem abgeschlossen.

Abgesehen davon, dass es wirklich “deutsche” Server sind, ist also der Hund drinnen. Weder SVC selbst noch die auf den Server installierten Tools helfen weiter.

Nach kurzer Recherche wurde ich tatsächlich fündig, dies ist bereits ein bekanntes Problem der IBM. Siehe: MPIO errors and Reservation Conflicts logged when attempts are made to move cluster resources on Windows 2012 with SDDDSM 2.4.3.3-5

Das Problem kann tatsächlich reproduziert werden, indem z.B. ein diskpart oder eine Computerverwaltung offen ist und eine Clusterrolle verschoben wird.

Der Fix ist übrigens bereits im seit dem 16. August öffentlich erhältlichen Treiber (2.4.3.4-4) verfügbar.