Nach dem Erstellen einer neuen “Custom Property” mit dem Namen “HDD-Typ SSD,SAS,SATA” (Sonderzeichen wie Klammern und Schrägstriche sind nicht zulässig und werden von der GUI abgefangen) stürzt die SCVMM Konsole sofort ab und lässt sich auch nicht wieder starten.

Der erste Fehler hat den Ereignisnamen “CLR20r3” an der “VmmAdminUI.exe”. Vermutlich gibt es für dieses Problem mittlerweile einen Patch, aber die verwendete Umgebung war nicht komplett gepatcht. Also musste eine Alternative her. Naheliegend war das Löschen der neu angelegten Eigenschaft, aber dies musste ohne GUI erfolgen (diese ließ sich wegen des Crashes ja nicht starten). Also bleibt nur die PowerShell…

Zunächst habe ich mit “Get-SCCustomProperty” nach der betreffenden Eigenschaft gesucht:

Der komplette Aufruf:

Get-SCCustomProperty | Where Name -NotLike "Custom*"

Danach kann man diese mit “Remove-SCCustomProperty” löschen:

Der komplette Aufruf:

Get-SCCustomProperty -Name "HDD-Typ SSD, SAS, SATA" | Remove-SCCustomProperty

Danach startet auch die Konsole wieder!

Hinweis: Zur Nutzung der SC-Kommandos muss das entsprechende Modul geladen sein. Dies geht am einfachsten, in dem man auf dem SCVMM-Server selbst die “Virtual Maschine Manager Command Shell” startet:

Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.

Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).

Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):

Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.

Glücklicherweise kündigt sich das bereits vorab an:

Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.

Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.

Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:

Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!

(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)

Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!

Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:

(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)

Wenn man im SCVMM 2012 R2 (gilt auch für “R1”) eine VM mit Hilfe einer VM-Vorlage (engl. “Template”) erzeugt, dann bekommt diese neue VM (und zwar unabhängig von dem bereits vorhandenen Betriebssystem in der eingesetzten VHD) alle Regionaleinstellungen auf “en-US”, dazu gehören u.a.:

• Tastaturlayout
• User-Locale
• System-Locale
• UILanguage

Die einzige Einstellung bezüglich der Region lässt sich für die Zeitzone einrichten:

Selbst wenn man mit Hilfe einer eigenen Antwortdatei andere Werte setzt, werden diese weitgehend ignoriert, da am Ende in der resultierenden Antwortdatei (Eigene Inhalte + im SCVMM gesetzte Einstellungen + SCVMM-Defaults) die SCVMM-Defaults am weitesten oben stehen und daher Vorrang bekommen.

Dieses Verhalten ist bei Microsoft bekannt und in dem folgenden KB-Artikel beschrieben:

http://support.microsoft.com/kb/2709539

Lösung des Problems

Als Workarround ist folgendes Vorgehen möglich:

1. SCVMM-Konsole starten
2. In den “Einstellungen”-Bereich wechseln
3. Dort die PowerShell über den Button in der Ribbon-Leiste öffnen
4. Ein angepasstes Script nach folgendem Schema ausführen

PowerShell-Script:

$Vorlage = Get-SCVMtemplate | where {$_.Name  -eq "Template_Name"}             
$Einstellungen = $Vorlage.UnattendSettings;            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/UserLocale","de-DE");            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/SystemLocale","de-DE");            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/UILanguage","de-DE");            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/InputLocale","0407:00000407");            
Set-SCVMTemplate -VMTemplate $Vorlage -UnattendSettings $Einstellungen

“Template_Name” muss hier natürlich durch den Namen der eigenen VM-Vorlage ausgetauscht werden. Das ganze sollte dann so aussehen:

Nun ist die VM-Vorlage entsprechend angepasst, was man per PowerShell abfragen kann:

(Get-SCVMtemplate | where {$_.Name  -eq "Name_der_Vorlage"}).UnattendSettings

Das Beispiel soll folgendes tun:

• Ein Orchestrator 2012 R2 Runbook überwacht den IIS-Dienst auf einer virtuellen Maschine (direkt, ohne SCOM; würde aber natürlich auch mit SCOM gehen)
• Fällt der IIS-Dienst aus, versucht Orchestrator, diesen neu zu starten
• Misslingt der Neustart des Dienstes, so wird die gesamte VM neugestartet (allerdings “von aussen”)
• Nach dem Neustart wird erneut der IIS geprüft
• Läuft der IIS-Dienst immer noch nicht, so wird die VM heruntergefahren und mit Hilfe von SCVMM eine neue Webserver-VM provisioniert

Im Einzelnen sind folgende Schritte nötig:

1. SQL-Datenbank-Server installieren
2. Zielsysteme für SCVMM und Orchestrator vorbereiten
3. SCVMM und Orchestrator installieren (dürfen auf einem System gemeinsam laufen, müssen aber nicht)
4. Integration-Pack für SCVMM beim Orchestrator einbinden. Dazu dient der “Deployment Manager”:

Die Runbooks kann man bei Microsoft aus dem TechNet beziehen. Nach dem Download müssen sie registriert und dann auf den Runbook Server bereitgestellt werden.

5. Konfiguration des Integration Packs im Runbook Designer:

Hierbei müssen die Verbindungsdaten zum SCVMM eingegeben werden.

6. Nun kann ein neues Runbook erstellt werden und mit den passenden Widgets bestückt und diese “verdrahtet” werden:

Zum Einsatz kommen hier im Beispiel folgende Widgets (vom Anfang zum Ende aufgezählt):

a) Überwachung / Dienststatus abrufen

b) System / Dienst starten/beenden

c) SC 2012 Virtual Machine Manager / Shut Down VM

d) SC 2012 Virtual Machine Manager / Start VM

e) Überwachung / Dienststatus abrufen

f) SC 2012 Virtual Machine Manager / Shut Down VM

g) SC 2012 Virtual Machine Manager / Create VM from Template

Die Einstellungen der jeweiligen Widgets möchte ich nun hier noch kurz zeigen:

Widget a)

Schleife um a)

Der Link zwischen a) und b)

Widget b)

Link zwischen b) und c)

Widget c)

Widget d)

Widget e) und f) analog zu den Widgets a) und c)

Widget g)

Wenn das Runbook fertiggestellt ist, kann es getestet werden. Dazu muss es ausgecheckt werden und anschliessend der Runbook-Tester gestartet werden:

Im Runbook-Tester wird das Runbook mitunter etwas anders optisch dargestellt:

Nach einem Klick auf “Ausführen” oben links startet das Runbook und arbeitet die einzelnen Schritte ab. Hier kann man u.a. sehen, dass weder der Neustart des Dienstes noch der Reboot der VM einen Erfolg brachten und daher nun eine neue VM erzeugt wird:

Dies lässt sich auch im SCVMM nachvollziehen:

Es fehlte einfach der Bereich „IP Adress“, dadurch lässt sich der Wizard auch nicht abschließen. Beim Überprüfen aller in Frage kommenden Faktoren, viel mir auf, dass die Netzwerkkarten der beiden Hyper-V-Hosts kein Gateway eingetragen hatten (IP + Subnetzmaske + DNS passten). Nachdem ich ein Gateway (welches die Hosts gar nicht erreichen können) auf beiden NICs eingetragen habe, zeigte der Wizard auch die entsprechende Einstellung an und erstellt den Cluster erfolgreich.

Im Nachgang habe ich das Ganze dann nochmal nachgestellt und den „klassischen“ Cluster-Assistenten verwendet, der vom Windows Server mitgeliefert wird. Dieser zeigt eine Warnung bezüglich des Gateways, stört sich aber sonst nicht weitere daran und erstellt den Cluster problemlos.