Bei Deployment von neuen Hyper-V Host schlägt der Prozess (New-SCVMHost) mit folgender Fehlermeldung fehl:

Error (21117)
Cannot find an OS present in the VHD which support native VHD boot

Recommended Action
Verify the vhd file

Die Meldung kann etwas irreführend sein, da das VHD Image unter Umstände völlig in Ordnung ist….

… denn die gleiche Meldung kommt auch wenn das Windows Automated Installation Kit (WAIK) in einer non-English Sprache installiert wurde. In solch einem Fall hilft ein kleiner Workaround:

1. WAIK Resource (CD, ISO) bereitstellen und in das Verzeichnis “x:\WinPE_LangPacks\amd64″ wechseln
2. Verzeichnis “en-us” nach “C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs” kopieren
3. In diesem Verzeichnis existieren nun zwei Ordner, das zuvor kopierte “en-us” und das Originale zum Beispiel “de-de”

Nachdem die richtigen Sprachen bereitgestellt wurden, muss dies nun noch in SCVMM respektive in WDS bereitgestellt werden:

1. Das WinPE Image Updaten
• Console: Fabric ⇒ PXE Server ⇒ Update WinPE Image
• Shell: Publish-SCWindowsPE -UseWindowsAIK
2. Bare Metal Deployment Vorgang erneut ausführen (Restart Job)

Werden 1-3 ausgeführt bevor der PXE Server zu VMM hinzugefügt wird, dann wird bereits von Beginn das korrekte WinPE Image erstellt / verwendet.

Bei einem Failover Cluster kann über die Eigenschaften einer Cluster Ressource definiert werden, welche Cluster Nodes berechtigt sind diese Ressource zu betreiben. In der Regel sind in der Liste der “Possible Owners”. sämtliche Cluster Nodes eingetragen. Auch wenn ein weiterer Cluster Node hinzugefügt wird, wird dieser automatisch als ein weiterer Possible Owner mitaufgenommen. In der Regel klappt dies auch, ausser wenn Probleme mit dem Zoning bestehen. Hat der neue Cluster Node (noch) keinen Zugriff auf das CSV würde dies einen “Redirected Access” verursachen.

(weiterlesen…)

Wird ein Hyper-V Cluster um einen weiteren Cluster Nodes erweitert, so lässt sich dieser sehr einfach mittels System Center Virtual Machine Manager in einen bestehenden Cluster integrieren. Einzige Bedinung, der neue Hyper-V Host muss bereits durch VMM verwaltet werden, damit dieser im “Add Cluster Node” Wizard ausgewählt werden kann. Wird allerdings das Bare Metal Deployment eingesetzt wäre dies bereits gegeben.

Ein Cluster Node kann mit folgendem Wizard zu einem Hyper-V Cluster hinzugefügt werden:

Doch was wenn dieser Prozess mit einer Fehlermeldung fehlschlägt? Ein gängiger Fehler ist folgender:

Error (25334)
Adding host hyperv03.backslash.li to the cluster hyperv.backslash.li failed because of error An error occurred while adding node ‘hyperv.backslash.li’ to cluster ‘hyperv’. The system cannot find the file specified.

Recommended Action
Please refer to cluster documentation for resolving cluster problems.

Only one could be added, the other three failed. We managed it by adding them to the cluster using Failover Cluster Manager.

In diesem Fall ist die Ursache leicht zu ermitteln, denn “Add” sowie “Remove” von Cluster Nodes erfordern die Failover Cluster PowerShell cmdlet (APIs). Das heisst, wenn in VMM Failover Cluster eine Add / Remove Aktionen durchgeführt werden sollen, so müssen die Failover Clustering Tools installiert sein. Sollten die Tools nicht (mehr) installiert sein, so lassen sich diese über den Server Manager, oder PowerShell einfach installieren:

Import-Module ServerManager
Add-WindowsFeature RSAT-Clustering

Wie erwähnt sollten ab SCVMM 2012 die Failover Clustering Tools eigentlich automatisch auf dem VMM Server installiert worden sein.

Export / Import von Virtual Machines ist eine beliebte Funktion in Entwicklungs- und Testumgebungen. Mit dem Virtual Machine Manager wird diese Funktion noch etwas optimiert. Denn Virtual Machines werden nicht einfach an einen beliebigen Ort exportiert, sondern in die VMM Library. Von dort aus kann diese auch sehr einfach wieder bei einem verwalteten VM Hosts importiert werden.

Damit eine VM in die Library verschoben werden kann, muss diese gestoppt, heruntergefahren oder in einem Saved State sein. Da dieser Status ebenfalls berücksichtigt wird, kann eine VM im Saved State unter Umständen auf einem VM Host mit einer abweichenden CPU nicht importiert werden. Was gilt es noch zu beachten? In der VMM Library wird ein Ordner mit sämtlichen Dateien angelegt. Dieser Ordner bleibt allerdings “hidden” bis der Job vollständig abgeschlossen wurde.

(weiterlesen…)

Viele Unternehmungsrichtlinien besagen, dass jedes Windows System einen Anti-Viren Scanner installiert zu haben braucht. Doch wenn diese Regel ganz ohne Anpassungen bei jedem Server einfach so angewendet wird, kann dies in einem grossen Problem enden. Wie zum Beispiel bei einem Exchange Server, oder eben auch bei einem Hyper-V Host.

In einem älteren Artikel wurde zwar bereits einmal darüber berichtet, doch scheint dies noch immer eine “heisse Diskussion” zu sein, weswegen ich eine überarbeitete Version zum Thema Anti-Virus Scanner mit Hyper-V veröffentliche. Denn noch immer gilt, werden bei Hyper-V die Konfiguration der Ausschlüsse nicht entsprechend angepasst, kann es zur Situation kommen wo sich Virtual Machines nicht mehr starten lassen (Fehlercode “0x800704C8″, “0×80070037″ oder “0x800703E3″). Im schlimmsten Fall verschwindet eine Virtual Machine sogar ganz aus der Hyper-V Management Console.

(weiterlesen…)

Troubleshooting ist eine Lehre für sich und nicht jedermanns Sache… Log Files, Event Viewer auswerten und anschliessend in Support Artikeln und Foren nach möglichen Lösungen suchen. Doch was wenn man dabei nicht fündig wird?

Bei Virtual Machine Manager wird es dann Zeit sich mit einem “Trace” auseinanderzusetzen. Für die Analyse wird DebugView von Sysinternals verwendet. Damit Traces erstellt werden, müssen verschiedene Tools eingesetzt und Konfigurationen vorgenommen werden:

1. DbgView Tool starten
2. Registry anpassen (Traces aktivieren)
3. VMM Services neu starten
4. Problem reproduzieren
5. Export von Traces
6. Registry anpassen (Traces deaktivieren)

(weiterlesen…)

Storage ist eines der wichtigsten Erfolgsfaktoren Virtualisierungs-Projekte. Ein sehr beliebtes Storage System kommt aus dem Hause HP und trägt den Namen p4000, früher auch bekannt unter dem Namen HP LeftHand p4000. Wie bereits andere Storage Lösungen folgt das p4000 auch dem GRID-Ansatz. Das Storage System besteht aus mehreren Storage Nodes welche in einem Cluster zusammengefasst werden. Jeder einzelne Node bietet als abgeschlossene Einheit die Kombination aus Speicherkapazität (SATA oder SAS), eigener Rechenleistung und Netzwerkbandbreite an.

Damit ein Host, wie zum Beispiel Hyper-V, eine fehlertolerante Verbindung mit mehreren iSCSI HBAs / NICs aufbauen kann, wird Multipath I/O (MPIO) mit zusätzlichem “Device Specific Module” (DSM) vom Storage Hersteller erweitert. Dieses Modul wird von HP als SAN/iQ bezeichnet.

Nebst MPIO installiert SAN/iQ auch den Hardware VSS Provider welcher für das Storage integrierte Backup verwendet werden kann. Diese erlauben es, Backups von Virtual Machines schnell und parallel durchzuführen indem die Hardware VSS Provider des Storage System angesprochen und Snapshots erstellt werden. Doch die Problematik liegt wiedermal im Detail…

SAN/iQ 8.5 wird zwar für Windows Server 2008 R2 und auch Hyper-V supported, doch wird Cluster Shared Volume (CSV) nicht speziell erwähnt. Dies kann zu grossen Problemen führen! Sobald ein Backup Job startet und das DSM anspricht, kann es zu Disk Deadlocks und schlussendlich zum Blue Screen “STOP: 0x0000009E” auf den Hyper-V Hosts kommen.

HP hat reagiert und im November 2010 ist die neueste SAN/iQ in der Version 9.0 erschienen. Dies sollte die Probleme adressieren und nun auch offiziell die Hardware VSS Provider für CSV Backups unterstützen. SAN/iQ 9.0  ist für die HP LeftHand p4000 G1 und G2 Modelle einsetzbar. Gemäss HP ist ein direktes Update von den Versionen 8.0, 8.1 und 8.5 möglich. Die Software kann kostenlos bei HP bezogen werden.

Wie jeden Monat ist wieder mal soweit, es ist Patch Day. Diesen Monat gilt es bei Hyper-V Server sieben (7) Recommended Updates zu installieren. Damit ein Hyper-V Host mit den aktuellsten Windows Updates bestückt und anschliessen neugestartet werden kann, gibt es im Virtual Machine Manager die nette Funktion “Maintenance Mode”.

Nun kann es vorkommen, dass dieser Modus nicht angewendet werden kann. Ebenfalls bricht die manuell initiierte Live Migration mit demselben Fehler ab. In der Job Übersicht wird dabei folgende Fehlermeldung angezeigt:

Error (10698)
Virtual machine MyVM could not be live migrated to virtual machine host MyHost using this cluster configuration.
(Unspecified error (0×80004005))

Recommended Action
Check the cluster configuration and then try the operation again.

Die Lösung, oder mehr die Ursache dieses Problem ist sehr einfach aufzuzeigen – der Host verfügt nicht über genügend Memory. VMM bricht daher den Job bei 50% ab, nachdem die Pre-Checks nicht erfolgreich waren. Der Failover Cluster bricht bereits schon nach 5% mit der Meldung “Migration attempt failed” ab.

Und nun? Als Workaround könnten nicht benötigte Virtual Machines heruntergefahren oder in einen “Save State” (Vorsicht mit dieser Funktion!) versetzt werden. Ist genügend Memory vorhanden, funktioniert auch Live Migration oder der Maintenance Mode.

Ein Storage welches in einem Failover Cluster genutzt werden sollt, muss zwingend die SCSI-3 Spezifikationen erfüllen. Denn mit Persistent Reservation kann ein Node durch das setzen einer Reservation Lese- und Schreibzugriffe von anderen Nodes unterbinden. Weil dadurch nie mehr als ein Node auf eine Cluster Disk zugreifen kann, wird bereits auf Storage-Ebene dem Split-Brain entgegengewirkt. Die Storage-Voraussetzungen werden auch explizit im Cluster Validation Wizard abgefragt und geprüft, wie zum Beispiel:

• List Potential Cluster Disks
• Validate SCSI-3 Persistent Reservation
• Validate Simultaneous Failover
• …

Unter bestimmten Umständen kann es nun aber zu einem Problem kommen, dass eine Disk Reservation nicht wieder aufgehoben (released) wird. In einem solchen Fall kann kein Node diese Disk mehr online nehmen und die Hochverfügbare Applikation (Exchange Server, Hyper-V, SQL Server) schlägt fehlt . (weiterlesen…)

Gemäss Handbuch wird ein Server nach der Installation und Konfiguration einem “Hardening” Prozess unterzogen. Somit werden alle nicht benötigten Dienste und Prozesse deaktiviert um die Angriffsfläche zu verkleinern. In diesem Zusammenhang wird in den meisten Fällen auch die Authentifizierung angepasst. Ein Active Directory kann NTLM, NTLMv2 sowie Kerberos zur Authentifizierung verwenden. Als eine Best Practice wird in diesem Zusammenhang empfohlen, dass ältere Protokoll NTLM im ganzen Netzwerk zu deaktivieren. Dazu kann zum Beispiel sehr einfach mittels einer Group Policy Object (GPO) umgesetzt werden: Computer Configuration ⇒ Policies ⇒ Windows Settings ⇒ Security Settings ⇒ Local Policies ⇒ Security Options ⇒ Network security: Restrict NTLM: …

Für Windows und Windows Server mag dies eine gute Einstellung sein, doch Hyper-V Failover Cluster hat mit dieser Einstellung ein Problem. Denn wird NTLM deaktiviert, so kann nicht mehr auf das CSV Volume zugegriffen werden. Im Event Log wird die folgende Fehlermeldung mit der ID 5121 festgehalten:

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Event ID: 5121
Task Category: Cluster Shared Volume
Level: Error
Symbolic Name: DCM_VOLUME_NO_DIRECT_IO_DUE_TO_FAILURE
Description: Cluster Shared Volume ‘Volume1′ (‘Cluster Disk 1′) is no longer available on this node because of ‘STATUS_BAD_NETWORK_PATH(c00000be)’. All I/O will temporarily be queued until a path to the volume is reestablished.

Um das Problem zu beheben ist es zwingend erforderlich dass die in dem Group Policy Object, welche NTLM deaktiviert, die Hyper-V Hosts ausgeschlossen werden. Es kann auch eine weitere GPO angelegt werden, welche speziell für den Hyper-V Failover Cluster NTLM wieder aktiviert. Einen Security Guide speziell für Hyper-V hat Microsoft bereits schon vor einigen Monaten veröffentlicht.

Eine sehr ähnliche Fehlermeldung zu Cluster Shared Volume hatten wir schon Mal vor einem Jahr. In diesem Artikel geht es ebenfalls um eine deaktivierte Funktion welche den Hyper-V Failover Cluster mit aktiviertem CSV ins Straucheln bringt…

Weitere Informationen

• Microsoft TechNet: Event ID 5121 — Cluster Shared Volume Functionality