Sehr langer Shutdown oder Reboot des Microsoft Hyper-V Server 2016

In den Windows Server 2016 haben sich je eine Reihe von Eigenheiten eingeschlichen, die mir immer wieder Probleme bereiten. Kürzlich hatte ich mit dem Microsoft Hyper-V Server 2016, wieder das Problem, dass einige Hosts für den Shutdown sehr lange benötigt haben. Mit sehr lange meine ich, bis zu einigen Stunden!

Daher habe ich mir das Problem genauer angeschaut und dabei die Lokation des Pagefiles als Auslöser ausmachen können. Damit kann die in diesem Blog beschriebene Lösung auch hier zum Einsatz kommen. Da der Microsoft Hyper-V Server keine Benutzeroberfläche hat, muss das Pagefile über WMIC neu konfiguriert werden.

Anzeige des aktuell konfigurierten Pagefiles.

wmic pagefile list full

Umstellung auf ein nicht durch das Betriebssystem konfiguriertes Pagefile.

wmic computersystem where name=”%computername%” set AutomaticManagedPagefile=False

Konfiguration des Pagefiles auf Laufwerk C: mit einer Startgröße von 16GB und einer maximalen Größe von 32GB. Soll das Pagefile mit einer festen Größe angelegt werden, dann ist es notwendig InitialSize und MaximalSize auf den gleichen Wert zu setzen.

wmic pagefileset where name=”C:\\pagefile.sys” set InitialSize=16384,MaximumSize=32768

Die Änderungen werden erst nach einem Neustart des Servers durch WMIC angezeigt, hier sollte man sich also nicht beirren lassen. Insofern WMIC keine Fehlermeldungen zurück gibt, ist die Konfiguration korrekt erfolgt.

Abschließend habe ich mir die Frage gestellt, wieso das Problem eigentlich auftritt. Ich kann dieses Verhalten nämlich nicht bei allen Hyper-V Hosts mit der Version 2016 feststellen. Microsoft selbst liefert in einer Reihe von Artikeln und Blogs Empfehlungen zur Dimensionierung von Pagefiles. Für Hyper-V Systeme, kann man das kurz abfassen.

  1. Geht dem Host der Speicher aus, und ist eine VM mit dynamisch allokiertem Speicher unterwegs dann erfolgt ein Paging in der VM und nicht auf dem Host
  2. Es genügt, dass der Host einen Kernel- oder von mir aus noch Active-Dump schreiben kann. Kernel-Dumps habe ich bisher, auch bei sehr großen Systemen (1TB … und mehr) keinen größer als 20GB gesehen und damit war er für eingehende Analysen immer ausreichend

Darum habe ich auf kleinen Hyper-V Hosts (32GB RAM und 64 bzw. 72GB Systemlaufwerk) keine Probleme gehabt und auch auf zwei meiner größeren Systeme mit 128GB RAM und einem 256GB großem Systemlaufwerk, ist das Problem nicht aufgetreten.

image

Lediglich auf mehreren Hosts mit 256GB RAM und einem 72GB großen Systemlaufwerk, bin ich auf dieses Problem getroffen und habe es wie oben beschrieben gelöst. Dabei ist verständlich, dass das Betriebssystem bei 256GB Hauptspeicher das Pagefile auf ein Laufwerk mit hinreichend viel Platz legt und es dadurch zu dem Verhalten kommen kann.

Enjoy it, b!

Server Core: Eine Alternative zum Resource Monitor

Windows Server Core und auch der Microsoft Hyper-V Server lassen die notwendigen Funktionen vermissen, damit der Windows Resource Monitor auf diesen ausgeführt werden kann.

Ich mag den Resource Monitor sehr, ermöglicht er doch einen schnellen Blick auf die Auslastung des Systems und zusätzlich zum Task Manager die Möglichkeit die Disks im Auge zu behalten.

Eine generelle Alternative zum Taskmanager, auch mit der Option diesen zu ersetzen, stellt der Process Monitor von Sysinternals dar. Dieser bietet eigentlich alles und noch viel mehr als dieser, zeigt aber wiederum die Netzwerkauslastung nicht so schön an.

Da der Versuch den Resource Manager zu starten, auf den Core Versionen des Windows Servers ohnehin nur eine Fehlermeldung produziert, dachte ich mir es wäre praktisch darüber den Process Explorer starten zu können.

Die folgende Abbildung zeigt das Problem …

image

… die Lösung dazu ist relativ einfach. Es muss lediglich ein Hardlink erstellt werden. Dabei wird der Pfad des Process Explorers als Resmon.exe in das Windows System Verzeichnis gelinkt.

:: Erstellen eines Hardlinks mit mklin.exe

C:\Windows\System32> mklink resmon.exe "c:\Program Files (x86)\Windows Sysinternals Tools\procexp.exe" /h
Hardlink created for resmon.exe <<===>> c:\Program Files (x86)\Windows Sysinternals Tools\procexp.exe

Mit diesem Workaround startet der Process Explorer und bietet über seine System Info einen Einblick zur aktuellen Auslastung (I/Os) der Platten.

image

Enjoy it, b!

Notepad++ läuft auf Windows Server Core

Für den Windows Server Core war ich schon einige Zeit auf der Suche nach einem ordentlichen Editor um auf Dev-Systemen Scripte etc. an zu passen …

Nun hatte ich neulich auf einem neuen System, wohl mehr ausversehen, ein Paket mit Notepad++ Version 7.x installiert (den Editor nehme ich unter Windows 10 und Windows Server mit GUI) und wahr überrascht, dass dieser problemlos funktionierte. Ich hatte Notepad++ vor sehr langer Zeit (das kann durchaus unter Windows Server 2008 Core) getestet und aus den Augen verloren – da er dort nicht funktionierte!

image

Here we go Smile

Enjoy it, b!

Update Avago / LSI 9261-4i Controller auf dem Windows Server Core

Meine Vorliebe für den Windows Server Core und vor allem den Microsoft Hyper-V Server dürfte bekannt sein. Das Arbeiten auf diesen System ist sehr mit der Kommandozeile behaftet, egal ob PowerShell oder die cmd.exe Verwendung finden.

Wenn irgendwie möglich setzte ich in meinen Server immer RAID-Controller von LSI (inzwischen Avago) ein. Der Weg dahin war vorgezeichnet:

  1. Mit den 3Ware Controllern fing alles an und 3ware wurde dann von LSI gekauft
  2. LSI kam bisher immer mit den 92xx-xi Controllern zum Einsatz, also 9240-4i, 9261-8i, 9271-8i, usw.
  3. Dann hat Avago LSI übernommen, führt aber die Controller weiter (im Gegensatz zu LSI, wo die 3Ware Controller nicht mehr weiterentwickelt wurden

Genug der Geschichten … der Update eines LSI Controllers auf Windows Server Core ist kein Hexenwerk, es müssen drei Komponenten aktualisiert werden.

  1. Management (MegaRAID Storage Manager)
  2. Firmware
  3. Windows Treiber

Die entsprechenden Pakete findet man auf der Avago Homepage und können dort herunter geladen werden. Die Links stammen vom Updates eines LSI MegaRAID 9261-8i.

Unter Support Documents and Downloads auf der Avago Homepage (http://www.avagotech.com) folgende Suche absetzen:

image

Alle Downloads entpacke ich in das Verzeichnis c:\temp\lsi – für die jenigen welche auf dem Server Core keine unzip.exe haben, einfach lokal entpacken und auf den Server drauf kopieren.

Das sieht dann wie folgt aus:

image

Wieso LSI den Storage Manager 2x verpackt hat, erschließt sich mir nicht – dennoch, irgendwann taucht mal die setup.exe auf.

Für uns sind hier nun folgende Dateien wichtig:

image

Im ersten Schritt machen wir ein Update des MegaRAID Storage Managers. Dabei werden, in dieser Version zumindest, alle Einstellungen gelöscht (also auch die Benachrichtigung per Email) welche im Anschluss dann wieder gesetzt werden müssen.

Dazu einfach c:\temp\lsi\msm\disk1\setup.exe starten und sich durch den Wizard klicken.

Der Storage Manager läßt sich danach über das folgende Script starten.

C:\Program Files (x86)\MegaRAID Storage Manager\startupui.bat

Diese Datei kopiere ich unter einem anderen Namen (mr.cmd) in folgendes Verzeichnis c:\program files\script (mit diesem ich die Pfad Variable erweitert habe) und nehme dazu folgende Modifikationen vor:

@Echo off

:: mr.cmd

rem %~d0
rem CD %~dp0

pushd "%ProgramFiles(x86)%\MegaRAID Storage Manager"

start JRE\bin\javaw -DVENUS=true -classpath .;GUI.jar;monitorgui.jar;DebugLog.jar;log4j-1.2.15.jar;jaxen-1.1.jar;jdom-1.1.jar GUI.VivaldiStartupDialog ajsgyqkj=71244

popd

Damit kann ich den Raid Manager von jedem beliebigen Verzeichnis aus starten.

Nun kann über den MegaRAID Storage Manager das Update der Controller Firmware vorgenommen werden.

image

Was bei LSI Controllern meistens online – also ohne einen Neustart erfolgen kann.

Zum Ende kommt nun noch die Installation des Windows-Treibers, welches ich über pnputil.exe erledige. Dazu muss ich in das Verzeichnis mit dem richtigen Treiber (win8.1_x64 = Windows Server 2012 R2) wechseln und folgenden Aufruf durchführen:

pnputil -i -a MegaSAS2.inf

Damit der Treiber dann auch geladen wird, ist allerdings ein Neustart notwendig. Mit SigCheck.exe aus den Sysinternals Tools läßt sich dann auch die Version des geladenen Treibers ermitteln.

C:\Temp>"\Program Files (x86)\Windows Sysinternals Tools\sigcheck.exe" C:\Window
s\system32\DRIVERS\megasas2.sys

Sigcheck v2.30 - File version and signature viewer
Copyright (C) 2004-2015 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\windows\system32\drivers\megasas2.sys:
        Verified:       Signed
        Signing date:   12:10 PM 9/10/2015
        Publisher:      Avago Technologies U.S. Inc.
        Company:        Avago Technologies
        Description:    MEGASAS RAID Controller Driver for Windows
        Product:        MEGASAS RAID Controller Driver for Windows
        Prod version:   6.709.12.00
        File version:   6.709.12.00
        MachineType:    64-bit

Falls nicht geschehen, nochmals das Alerting (per Emails) konfigurieren.

Enjoy it, b!