Fehlerbehebung bei Storage-Problemen unter Hyper-V

Die Hyper-V-Plattform bewährt sich bei der Diagnose und Behebung von Storage-Problemen. Trotzdem sollte man wissen, was schief gehen kann.

Eine der angenehmen Eigenschaften von Microsofts Hyper-V ist die einfache Handhabung, zumindest im Vergleich mit...

anderen Plattformen für die Server-Virtualisierung. Im Allgemeinen läuft Hyper-V stabil und zuverlässig, aber gelegentlich machen sich doch Storage-Probleme bemerkbar. Diese können fehlgeschlagene Backups zur Folge haben, virtuelle Maschinen funktionsunfähig machen und sogar zum Absturz des Host-Servers führen. Die relative Einfachheit der Plattform ist einerseits sehr nützlich, wenn es um die schnelle Diagnose und Behebung von Storage-Problemen geht. Trotzdem ist es wichtig zu verstehen, was sonst noch schief gehen kann.

Eines der häufigsten Storage-Probleme, mit denen man es unter Hyper-V zu tun bekommen kann, besteht in korrupten virtuellen Maschinen, die dann nicht mehr gestartet werden können; in manchen Fällen sind auch einzelne Module einer VM nicht mehr ansprechbar. Hier einige Beispiele für die Fehlermeldungen, die in solchen Situationen angezeigt werden:

  • "The requested operation cannot be performed on a file with a user-mapped section open (0x800704CB)."
  • "'VMName' Microsoft Synthetic Ethernet Port (Instance ID{7E0DA81A-A7B4-4DFD-869F-37002C36D816}): Failed to Power On with Error 'The specified network resource or device is no longer available' (0x80070037)."
  • "The I/O operation has been aborted because of either a thread exit or an application request (0x800703E3)."

Alle diese Probleme werden durch den unsachgemäßen Gebrauch von Antivirus-Software verursacht. Oft werden Programme dieser Art vom Administrator auf dem Host-Betriebssystem installiert, ohne zu berücksichtigen, welche negativen Auswirkungen dies auf den virtuellen Server haben kann. Im Allgemeinen gilt hier die Regel, dass Antivirus-Programme, die auf dem Betriebssystem des Hosts laufen, so zu konfigurieren sind, dass Verzeichnisse mit VM-Konfigurationsdateien vom Virus-Scan ausgenommen bleiben. Das gleiche gilt für Verzeichnisse, in denen sich virtuelle Laufwerke oder Snapshots von virtuellen Maschinen befinden. Darüber hinaus empfiehlt Microsoft, die Dateien Vmms.exe und Vmwp.exe nicht auf Viren scannen zu lassen.

Läuft auf dem Host-Server das Betriebssystem Windows Server 2008 R2 und wird der Server dabei unter Hyper-V als Cluster-Knoten betrieben, dann muss der Ordner „ClusterStorage“ auf Laufwerk C ebenfalls von Scans ausgenommen werden. Dieses Verzeichnis verweist unmittelbar auf das Cluster Shared Volume, in dem sich üblicherweise die Dateien der virtuellen Maschine befinden.

Blue Screen of Death auf dem Host-Server

Als weiteres mögliches Problem unter Hyper-V kann es auf dem Host-Server zu einem Blue Screen of Death (BSOD) kommen. Der Fehlerbildschirm kann durch eine Reihe verschiedener Ereignisse ausgelöst werden, am häufigsten durch korrupten Arbeitsspeicher. Gelegentlich werden Administratoren aber auch jedes Mal mit einem BSOD konfrontiert, wenn sie versuchen, ein Backup des Hyper-V-Hosts anzustoßen.

Um zu ermitteln, ob der BSOD auf das Backup zurückzuführen ist oder nicht, kann man zunächst ganz einfach in den Server-Protokollen nachsehen, ob der Zeitpunkt des Absturzes mit dem des Backups zusammenfällt. Sollte sich der Backup-Prozess tatsächlich als Ursache herausstellen, dann bieten sich zur Behebung verschiedene Maßnahmen an.

Zunächst sollten Sie sicherstellen, dass sowohl für Storage- als auch für Backup-Hardware die aktuellste Version der Firmware installiert ist. Eine obsolete Firmware kann gelegentlich dazu führen, dass sich der Backup-Prozess unwiederbringlich aufhängt.

Falls Ihre Installation ein Cluster Shared Volume beinhaltet, dann sollten Sie auch überprüfen, ob das verwendete Backup-Programm dieses Feature tatsächlich unterstützt. Viele der für Hyper-V verfügbaren Backup-Produkte sind nicht Cluster-fähig. Das Backup eines Cluster Shared Volume mit einem derartigen Programm führt eher selten zu einem nicht behebbaren Fehler, aber es lässt sich auch nicht ausschließen. Am häufigsten erhält man als Ergebnis ein fehlerhaftes Backup.

Schließlich kann der BSOD auch mit einem Problem beim Volume Shadow Copy Service (VSS) zusammenhängen. VSS kommt bei Backups unter Hyper-V zum Einsatz, um sicherzustellen, dass die Daten virtueller Maschinen nicht verändert werden, solange die Sicherung im Gange ist. Der tatsächliche Kopiervorgang wird durch einen VSS-Provider ermöglicht. Oft stammt dieser von Microsoft, und der Kopiervorgang wird über das Windows-eigene Dateisystem abgewickelt. Wird jedoch eine spezielle Storage-Hardware verwendet, dann hat deren Anbieter möglicherweise seinen eigenen VSS-Provider mitgeliefert. Solche Hardware-spezifischen Provider sind gelegentlich bereits als Auslöser für einen BSOD aufgefallen. Wenn Sie vermuten, dass der verwendete VSS-Provider den Fehler verursacht hat, dann sollten Sie mit Hilfe des Herstellers ermitteln, ob Sie die  aktuellste Version installiert haben und diese auch korrekt beim Betriebssystem registriert ist.

Storage Contention

Eines der häufigsten Probleme bei Hyper-V ist die sogenannte Storage Contention (kollidierende Speicherzugriffe). Denn unabhängig davon, ob bei einem virtuellen System dedizierte Storage-Geräte oder ein Cluster Shared Volume zum Einsatz kommen, stehen alle virtuellen Maschinen auf dem Host im Wettstreit um den verfügbaren Festplatten-I/O. Bei der Verwendung eines Cluster Shared Volume müssen alle virtuellen Maschinen auf allen Hosts des Clusters um den Laufwerkszugriff kämpfen, weil ja alle Hosts mit demselben Storage-Volume verbunden sind.

Zum Problem wird Storage Contention dann, wenn das Storage-Subsystem nicht mehr genügend I/O-Kapazität für alle virtuellen Maschinen zur Verfügung stellen kann. Dies kann entweder durch einen Engpass im Storage-Array selbst oder durch die begrenzte Bandbreite des Storage-Netzwerks bedingt sein. Der einzig wirklich gangbare Weg zur Behebung besteht hier im Einsatz von Programmen zur Performance-Überwachung. Mit deren Hilfe kann man den Engpass ausfindig machen und dann ein Upgrade der entsprechenden Hardware vornehmen.

In manchen Fällen können Sie auch versuchen, die Symptome einer solchen Kollision abzumildern, indem Sie für die VMs geplante Workloads zeitlich verschieben. So sind gerade Backups dafür bekannt, dass sie in erheblichem Maße die Festplatten-I/O beanspruchen. Wenn also beispielsweise mehrere virtuelle Maschinen auf der Ebene der Gast-Systeme gesichert werden sollen, dann bietet es sich an, diese Backup-Vorgänge nicht alle gleichzeitig laufen zu lassen. Dadurch verringert sich die damit einhergehende I/O-Beanspruchung.

Brien Posey ist freiberuflicher Autor und sechsfacher Träger des MVP-Awards von Microsoft. Er war als CIO einer US-weiten Krankenhauskette und anderer Unternehmen im Gesundheitssektor tätig und hat als Netzwerk-Administrator für das US-Verteidigungsministerium in Fort Knox gearbeitet.

Artikel wurde zuletzt im Juli 2012 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Datenspeicherlösungen für virtuelle Server

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close