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

Damit Virtual Machines auf ein Netzwerk zugreifen können, ist ein Virtual Network erforderlich. Der Virtual Network Manager kann einen allerdings schon mal Kopfzerbrechen bereiten, wie auch schon im Artikel “How-To: Netzwerkkarten Teaming mit Hyper-V” beschrieben wurde.

Die meisten Probleme Herausforderungen treten bei Server Core auf – Allerdings kann es auch bei einer Full Installation zu Fehlermeldungen kommen, wenn ein neues Virtual Network angelegt wird:

Error Applying New Virtual Network Changes
The operation on computer %Computername% failed.

Diese Meldung kommt dann, wenn im Hintergrund noch die Eigenschaften dieses Network Adapters offen sein sollten. Wird das offene Fenster geschlossen, kann der Vorgang umgehend abgeschlossen werden!

Diese Meldung ist, aufgrund der Arbeitsweise der zugrunde liegenden API’s, (leider) zu erwarten. Wenn das Fenster mit den Eigenschaften des Network Adapters zuerst geladen wird, wird im Hintergrund die API “INetCfg” blockiert damit kein anderer Prozess eine Änderung durchführen kann. Diese Blockierung wird erst dann wieder aufgehoben, wenn die Eigenschaften wieder geschlossen werden.

Im oberen Beispiel kann daher auch der Hyper-V Management Code die Sperre der INetCfg API nicht umgehen um ein “bind” des Switch Protokolls auf den Network Adapter durchzuführen.

In diesem Artikel wird beschrieben, wie eine Failed VM in Virtual Machine Manager repariert werden kann. Dieses Troubleshooting, auch als “Notes from the field” bekannt, sollte auch aufzeigen wie ein Problem in VMM analysiert werden kann… Zur Situation: Bei einer von VMM verwaltete Virtual Machine wurde jeder Job / jede Änderung abgebrochen.

Eine solche Situation kann zum Beispiel dann vorkommen, wenn eine clustered VM (HAVM) in Hyper-V exportiert und auf einem anderen Cluster Node wieder importiert wird. Beim erneuten Hinzufügen in den Failover Cluster wird allerdings automatisch eine neue ID erstellt. Wird VMM bei einer solchen Aktion ausgelassen, kommt die #CLUSTER-INVARIANT# Information zum Zug, darüber kann VMM eine bekannte VM eindeutig zuweisen. Leider funktioniert dies bei Export / Import (noch) nicht…

Im Job-Log wurde folgende Fehlermeldung ausgegeben:

Error (12711)
VMM cannot complete the WMI operation on server MyDamagedVM.intra.server-talk.eu because of error: [MSCluster_ResourceGroup.Name="dced5bf8-493b-49b7-8295-ee079d008b1f"] The cluster group could not be found.
(The cluster group could not be found (0×1395))

Recommended Action
Resolve the issue and then try the operation again.

Die Virtual Machine wird in Virtual Machine Manager mit dem Status Failed dargestellt. Ist die VM gestartet, läuft diese zwar uneingeschränkt weiter, allerdings könne in VMM keine  Aktionen mehr ausgeführt werden, selbst die Funktion “Repair” schlägt fehl…

(weiterlesen …)

Diese Woche hat Nils Kaczenski von faq-o-matic.net ein Artikel zu “LUN auswerfen?!” gepostet. Bei näherer Betrachtung hat sich herausgestellt, dass dieser Server virtuell betrieben wird und die LUNs als Wechselhardware angezeigt werden. Da dies bei manchen Servern sehr unangenehm sein kann, wenn ein Laufwerk einfach so entfernt würde, schauen wir uns die Ursache mal etwas genauer an…

Bei Hyper-V werden Datenträger entweder an einen IDE- oder SCSI-Controller angeschlossen. Da man mit SCSI weitaus eine grössere Zahl von Devices verwalten kann, sowie auch im laufenden Betrieb ohne downtime weitere Hard Disks hinzugefügt werden können, wird empfohlen für Daten Disks ausschliesslich den SCSI-Controller zu verwenden. Auch Pass-through Disks werden mit einem SCSI-Controller konfiguriert.

Nun ist es so, dass alle Hard Disks welche an einem solchen SCSI-Controller angeschlossen sind, als auswerfbar angezeigt werden. Mit einem Klick auf das Task Icon “Safely Remove Hardware and Eject Media” lässt sich die Disk auswerfen (“Eject Msft Virtual Disk SCSI Disk Device”):

Was passiert nun, wenn eine Hard Disk ausgeworfen wurde? Windows Server führt diese Aktion entsprechend durch und die Disk wird auch aus dem Storage Manager entfernt. Diese bleibt solange “verschwunden” bis a) der Server neu gestartet wird, oder b) die VHD in den Virtual Machine Settings re-attached wird. Übrigens, da IDE Hard Disks, wie zum Beispiel auch die System Disk, nicht online hinzugefügt werden können, werden diese Laufwerke auch nicht als auswerfbar angezeigt.

Ironischerweise ist die Anzeige im Device Manager korrekt und die Hard Disk wird nicht als “Devices with removable storage” aufgeführt:

Dieses Verhalten ist auch bei Windows Server 2008 R2 (Beta) mit installiertem Service Pack 1 noch so. Workaround? Eigentlich kein richtiger – “Safely Remove Hardware and Eject Media” kann zum Beispiel von der Taskbar ausgeblendet werden…

By the way – auch bei VMware werden Devices zum Auswerfen angezeigt:

Microsoft empfiehlt für den produktiven Einsatz von Hyper-V den Core Installation Mode zu wählen. Denn die Vorteile des Server Core liegen für die Virtualisierung eigentlich ganz klar auf der Hand:

• Wartung – Da bei einer Server Core Installation nur das installiert wird, was zur Verwaltung einer Rolle erforderlich ist, fällt weniger Wartungsaufwand an.
• Angriffsfläche – Systemdateien sind nur in minimalem Umfang installiert. Dadurch dass nur wenige Dienste und Anwendungen laufen, verringert dies die Angriffsfläche.
• Management – Da auf einem Server im Core Installation Mode nur wenige Applikationen und Dienste vorhanden sind, sinkt der Verwaltungsaufwand.
• Speicherplatzbedarf – Server Core benötigt zur Installation nur etwa 1 Gigabyte (GB) Disk Space. Im Anschluss daran sind beim Betrieb lediglich rund 2 GB erforderlich.

Wie die Installation von Hyper-V auf Basis von Server Core durchgeführt werden kann, wird in einem älteren Artikel bereits beschrieben. Mit dem in Windows Server 2008 R2 hinzugefügten “sconfig” geht dies  inzwischen ganz flott. Nun hat sich herausgestellt, dass bei manchen ProLiant Server von HP zu Problemen kommen kann. Beim Anlegen des Failover Cluster wird folgende Fehlermeldung angezeigt:

An error occurred while creating the cluster. An error occurred creating cluster ‘clustername’.
The service has not been started.

(weiterlesen …)

Mit Hyper-V ist es möglich einer Virtual Machine mehrere Prozessoren zuzuweisen. Dies wird auch als “Symmetric Multiprocessing” oder kurz “SMP” bezeichnet. Vom Hypervisor werden in der Version 2008 R2 Konfigurationen mit 1, 2, 3 und 4 Virtuellen Prozessoren unterstützt. Je nach  Operating System unterscheidet sich allerdings die Anzahl der Prozessoren, welche durch Microsoft supported wird:

• Windows Server 2008 (R2): 1, 2, oder 4 Virtuelle Prozessoren
• Windows Server 2003 mit Service Pack 2: 1, oder 2 Virtuelle Prozessoren
• Windows 2000 Server mit Service Pack 4: 1 Virtueller Prozessor

Technisch gesehen können natürlich auch Virtual Machines mit mehr als 1, oder 2 Virtuellen Prozessoren konfiguriert werden. Das  Operating System wird dies auch entsprechend identifizieren, allerdings wurde diese Konfiguration, zum Beispiel für Windows Server 2003, nicht durch Microsoft getestet und ist daher auch nicht supported. Bei einer Störung muss das Problem zunächst bei einer Virtual Machine mit 2 Prozessoren reproduziert werden können.

(weiterlesen …)

Mit Windows Virtual PC (VPC) und dem neuen Tool Disk2VHD von Sysinternals wurde ein kleiner Hype entfacht, wobei viele Administratoren versucht haben, ihren persönlichen Computer in eine Virtual Machine zu konvertieren. In Zeiten von Hard Disks im Terrabyte Bereich wurde die Euphorie schnell von einer Limitation in Virtual PC gebremts. Denn VPC kann mit Virtual Hard Disks (VHDs) grosser als 127.5 GB nicht umgehen. Der Vorgang eine solches VHD Image in hinzuzufügen wird mit folgender Fehlermeldung abgebrochen:

The virtual hard disk image ‘.\My Virtual Machines\WS2008.vhd’ is too large for the IDE bus. Make sure that all virtual hard disk images connected to the IDE bus are not greater than 127.5 GB.

Für ein Resize eines solchen VHD Image, kann nicht nur die Virtual Hard Disk verkleinert werden. Auch die darauf angelegten Volumes müssen vorgängig auf die neue Grösse angepasst, sprich verkleinert werden.

Resize Volume

Das Volume kann auf einem Host System wie Windows 7, oder Server 2008 R2 sehr einfach verkleinert werden. Dazu muss lediglich ein Command Prompt als Administrator geöffnet und Diskpart ausgeführt werden. Nachdem eine Virtual Hard Disk geladen / attached wurde kann bereits das gewünschte Volume verkleinert werden. Sinnvoll ist es das Volume vor der Konvertierung zu defragmentieren, da ansonsten zu viel verteilter Speicherplatz belegt wird. Im nachfolgenden Beispiel wird ein Volume vom VHD Image “TestW7.vhd” auf 100 GB verkleinert:

C:\> diskpart
DISKPART> list vdisk
DISKPART> select vdisk file=D:\TestW7.vhd
DISKPART> attach vdisk
DISKPART> list volume
DISKPART> select volume 4
DISKPART> shrink desired=102400
DISKPART> detach vdisk
DISKPART> exit

Wird bei “shrink” kein spezifischer Wert angegeben (desire=), so wird automatisch der maximal mögliche Wert genommen.

Resize VHD Image

Im nächsten Schritt muss auf das Tool VHD Resizer zurückgegriffen werden. Der VHD Resizer kopiert den Inhalt eines VHD Image blockweise in eine neue Datei. Der Vorteil hierbei ist, dass das Original Image erhalten bleibt und somit keine Daten verloren gehen (sollten). Damit die “Volume ID” nicht verändert wird, muss zwingend eine Kopie auf Blocklevel durchgeführt werden.

Die Handhabung von VHD Resizer ist einfach, nach der Installation muss lediglich das Source und Target VHD Image, sowie die neue Grösse (maximal 127 GB) angegeben werden, damit der Kopiervorgang gestartet werden kann. Ist die Datei allerdings zu diesem Zeitpunkt noch im Zugriff durch eine andere Applikation wie VPC, oder Disk Management, so wird die Meldung “Invalid Disk, please select another” ausgegeben.

Die Konvertierung in das neue VHD Image wird mit “Resize complete, resize another” abgeschlossen. Das Tool schliess sich übrigens automatisch, wenn “no” angewählt wird… Danach kann das neu angelegte Image der entsprechenden Virtual Machine hinzugefügt werden.

Download

vmToolkit VHD Resizer kann direkt beim Hersteller heruntergeladen werden.

[box type="download" size="medium"] VhdResize-1.0.42.zip (170 KB) [/box]

Weitere Informationen

• Server Talk: Sysinternals “Disk2vhd”
• Server Talk: How-To: Resize von VHD Files