DE112010004182T5

DE112010004182T5 - Verfahren und System für die Fehlerverwaltung in virtuellen Rechnerumgebungen

Info

Publication number: DE112010004182T5
Application number: DE112010004182T
Authority: DE
Inventors: David Richard Franklin
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-10-30
Filing date: 2010-08-31
Publication date: 2012-08-30
Also published as: CN102597962B; GB2487494A; CN102597962A; JP2013509626A; GB2487494B; GB201203864D0; WO2011051025A1; JP5643321B2; US20110107148A1; US8381033B2

Abstract

Bereitgestellt wird ein Verfahren und System für die Fehlerverwaltung in virtuellen Rechnerumgebungen. Das System beinhaltet: eine Überwachungseinheit für Fehlerereignisse virtueller Maschinen und Host-Einheiten in einer virtuellen Rechnerumgebung und eine Überwachungseinheit für Situationsereignisse in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen. Eine Komponente für universelle Fehler ermittelt, ob ein Fehlerereignis sowohl virtuelle Maschinen als auch Host-Einheiten betrifft, und eine Korrelierungskomponente stellt eine Beziehung zwischen Fehlerereignissen, die sich auf virtuelle Maschinen und auf Host-Einheiten beziehen, als zu demselben Problem gehörig her. Host-Maschinen-Fehlerereignisse, die in Beziehung zu einem Problem stehen, werden als ein Ursachen-Ereignis gekennzeichnet, und Fehlerereignisse virtueller Maschinen, die in Beziehung zu einem Problem stehen, werden als Symptome mit einer Verknüpfung zu dem Ursachen-Ereignis gekennzeichnet.

Description

Technisches Gebiet
Diese Erfindung bezieht sich auf das Gebiet der Fehlerverwaltung. Insbesondere bezieht sie sich auf die Fehlerverwaltung in virtuellen Rechnerumgebungen.
Hintergrundinformationen
Es ist üblich, Betriebssysteme in virtuellen Umgebungen auszuführen. Diese dienen wiederum zur Ausführung von Anwendungen, die eine Reihe von Diensten realisieren. Jede virtuelle Maschine (VM) repliziert direkt einen physischen Computer, wird jedoch unter einem Hypervisor auf einer physischen Host-Maschine ausgeführt. Eine Host-Maschine kann mehrere VMs aufnehmen. Um eine möglichst hohe Auslastung der Host-Maschine zu erzielen und die Fehlertoleranz zu erhöhen, laufen VMs häufig auf einer Gruppe von Host-Maschinen. Wenn eine Host-Maschine ausfällt, können die VMs verschoben (bzw. verlagert) werden, um auf einer anderen Host-Maschine der Gruppe ausgeführt zu werden.
Auf VMs können Fehler auf ähnliche Art und Weise auftreten wie auf physischen Maschinen. Anhand von Fehlerverwaltungssystemen können diese Probleme erkannt, überwacht und an einen Bediener gemeldet werden, um so eine schnelle Behebung zu ermöglichen. So ist z. B. IBM^® Tivoli^® Netcool^® ein Verwaltungssystem auf Dienstebene, das unternehmensweite Ereignisdaten von verschiedenen Netzwerkdatenquellen erfasst, darunter auch Fehlerereignisse (IBM, Tivoli und Netcool sind Handelsmarken der International Business Machines Corporation, die in vielen Rechtsräumen weltweit eingetragen sind).
In einer virtuellen Umgebung können Fehler durch Fehler auf dem Host-Hypervisor-System verursacht werden, das die VM ausführt. Wenn viele VMs von einem einzigen Host ausgeführt werden, kann dies möglicherweise dazu führen, dass eine Flut von Fehlern gemeldet wird, die jedoch nicht durch Fehler auf den eigentlichen VMs verursacht werden. Für einen Bediener kann es verwirrend und zeitaufwändig sein, dies durchzuarbeiten und schnell zu beheben. Zudem kann, selbst wenn eine Hypervisor-Fehlerüberwachung realisiert ist, dieser (oft weniger schwerwiegende) Ursachenfehler in der Flut von VM-Fehlerereignissen untergehen und von dem Bediener übersehen werden.
Daneben besteht ein Weg zum Beheben mancher Fehler auf VMs darin, sie auf eine andere physische Host-Maschine zu verschieben. Dies führt zur sofortigen Behebung einiger Probleme, wobei jedoch herkömmliche, auf diesen VMs ausgeführte Fehlerüberwachungssysteme möglicherweise nur langsam in der Lage sind, diese Änderung des Zustands zu aktualisieren und das Problem zu bereinigen.
Aus diesem Grund besteht in der Technik ein Bedarf, das oben genannte Problem zu lösen.
Zusammenfassung
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren für die Fehlerverwaltung in virtuellen Rechnerumgebungen bereitgestellt, das Folgendes umfasst: Überwachen von Fehlerereignissen virtueller Maschinen und Host-Einheiten in einer virtuellen Rechnerumgebung; Überwachen von Situationsereignissen in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen; Ermitteln, ob ein Fehlerereignis sowohl virtuelle Maschinen als auch Host-Einheiten betrifft; Herstellen einer Beziehung zwischen Fehlerereignissen, die sich auf virtuelle Maschinen und Host-Einheiten beziehen, als zu demselben Problem gehörig.
Das Verfahren kann Folgendes beinhalten: Pflegen einer Tabelle zum Zustand virtueller Maschinen; und Pflegen einer Abbildung von Namen virtueller Maschinen und von Namen von Host-Einheiten.
Das Verfahren kann ferner das Einfügen von Fehlerereignissen in eine Tabelle von Fehlerereignissen beinhalten. Host-Maschinen-Fehlerereignisse, die in Beziehung zu einem Problem stehen, können in der Tabelle der Fehlerereignisse als ein Ursachen-Ereignis gekennzeichnet werden. Fehlerereignisse von virtuellen Maschinen, die in Beziehung zu einem Problem stehen, können in der Tabelle der Fehlerereignisse als Symptome gekennzeichnet werden, und eine Verknüpfung zu dem Ursachen-Ereignis kann in die Tabelle der Fehlerereignisse aufgenommen werden.
Wenn eine virtuelle Maschine auf eine neue Host-Maschine verschoben wird, können alle Fehlerereignisse der virtuellen Maschine in der Tabelle der Fehlerereignisse aufgefunden und ihr Schweregrad verringert werden. Zusätzlich kann eine Ursachenverknüpfung entfernt werden.
Die Situationsereignisse können durch ein Überwachungssystem überwacht werden, von dem eine Prüfroutine Ereigniswarnmeidungen zuführt, und eine Angabe zu Beziehungen zwischen einer virtuellen Maschine und einer Host-Einheit und Host-Fehlerereignissen beinhalten.
Die Fehlerereignisse in den virtuellen Maschinen können durch Prüfroutinen zugeführt werden, die auf den virtuellen Maschinen ausgeführt werden, und die Fehlerereignisse in den Host-Maschinen können durch Prüfroutinen zugeführt werden, die auf den Host-Maschinen ausgeführt werden.
Die Fehlerereignisse in den Host-Maschinen können durch ein Überwachungssystem überwacht werden, von dem eine Prüfroutine Ereigniswarnmeldungen zuführt.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Computer-Software-Produkt für die Fehlerverwaltung in virtuellen Rechnerumgebungen bereitgestellt, wobei das Produkt ein computerlesbares Speichermedium umfasst, das einen Computer speichert, in dem durch einen Computer ausführbare Befehle gespeichert sind, wobei die Befehle, wenn sie durch einen Computer gelesen und ausgeführt werden, die folgenden Schritte durchführen: Überwachen von Fehlerereignissen virtueller Maschinen und Host-Einheiten in einer virtuellen Rechnerumgebung; Überwachen von Situationsereignissen in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen; Ermitteln, ob ein Fehlerereignis sowohl virtuelle Maschinen als auch Host-Einheiten betrifft; Herstellen einer Beziehung zwischen Fehlerereignissen, die sich auf virtuelle Maschinen und Host-Einheiten beziehen, als zu demselben Problem gehörig.
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein System für die Fehlerverwaltung in virtuellen Rechnerumgebungen bereitgestellt, das Folgendes umfasst: einen Prozessor; eine Überwachungseinheit für Fehlerereignisse virtueller Maschinen und Host-Einheiten in einer virtuellen Rechnerumgebung; eine Überwachungseinheit für Situationsereignisse in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen; eine Normalisierungskomponente für das Ermitteln, ob ein Fehlerereignis sowohl virtuelle Maschinen als auch Host-Einheiten betrifft; und eine Korrelierungskomponente für das Herstellen einer Beziehung zwischen Fehlerereignissen, die sich auf virtuelle Maschinen und Host-Einheiten beziehen, als zu demselben Problem gehörig.
Das System kann eine Tabelle zum Zustand virtueller Maschinen und eine Abbildung von Namen virtueller Maschinen und von Namen von Host-Einheiten beinhalten.
Das System kann ferner eine Tabelle von Fehlerereignissen für das Pflegen einer Liste von Fehlerereignissen beinhalten, die sich auf virtuelle Maschinen oder Host-Einheiten beziehen. Das System kann in der Tabelle der Fehlerereignisse eine Ursachen-Ereignis-Kennzeichnung für Host-Maschinen-Fehlerereignisse beinhalten, die in Beziehung zu einem Problem stehen. Das System kann ferner in der Tabelle der Fehlerereignisse eine Symptom-Kennzeichnung für Fehlerereignisse virtueller Maschinen, die in Beziehung zu einem Problem stehen, und eine Verknüpfung zu dem Ursachen-Ereignis in der Tabelle der Fehlerereignisse beinhalten.
Das System kann eine Fehlerbehebungskomponente beinhalten, wobei, wenn eine virtuelle Maschine auf eine neue Host-Maschine verschoben wird, die Behebungskomponente alle Fehlerereignisse der virtuellen Maschine in der Tabelle der Fehlerereignisse auffindet und den Schweregrad der Ereignisse verringert.
Die Überwachungseinheit für Situationsereignisse kann die Situationsereignisse von einem Steuerungszentrum der virtuellen Umgebungsgruppe erhalten und dem Fehlerverwaltungssystem Ereigniswarnmeldungen zuführen.
Die Überwachungseinheit für Fehlerereignisse kann aus Prüfroutinen bestehen, die auf den virtuellen Maschinen ausgeführt werden, und die Überwachungseinheit für Fehlerereignisse kann aus Prüfroutinen bestehen, die auf den Host-Maschinen ausgeführt werden.
Die Überwachungseinheit für Fehlerereignisse in den Host-Maschinen kann die Fehlerereignisse von einem Steuerungszentrum der virtuellen Umgebungsgruppe erhalten und dem Fehlerverwaltungssystem Ereigniswarnmeldungen zuführen.
Die Prüfroutinen können auf einer entfernten Maschine ausgeführt werden und die Host-Maschine über ein Netzwerk überwachen.
Unter einem vierten Aspekt betrachtet, stellt die vorliegende Erfindung ein Computerprogramm bereit, das auf einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers geladen werden kann, welches Softwarecode-Teile umfasst, die, wenn das Programm auf einem Computer ausgeführt wird, die Schritte des Verfahrens durchführen.
Kurze Beschreibung der Zeichnungen
Im Folgenden wird die vorliegende Erfindung lediglich beispielhaft und mit Bezug auf bevorzugte Ausführungsformen beschrieben, wie sie in den folgenden Figuren dargestellt werden:
1 ist ein Blockschaubild einer bevorzugten Ausführungsform eines Systems gemäß der vorliegenden Erfindung;
2 ist ein Blockschaubild eines Objekt-Servers eines Systems gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung;
3 ist ein Blockschaubild, das ein Computersystem zeigt, in dem eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann;
4 ist ein Ablaufplan eines Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung; und
5 ist ein Ablaufplan eines Verfahrens gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Ausführliche Beschreibung der Erfindung
Es dürfte klar sein, dass aus Gründen der Einfachheit und Klarheit der Darstellung die in den Figuren gezeigten Elemente nicht notwendigerweise maßstabsgerecht gezeichnet wurden. So können aus Gründen der Klarheit die Abmessungen einiger der Elemente relativ zu anderen Elementen vergrößert dargestellt sein. Wo dies als angemessen betrachtet wurde, können ferner Bezugsziffern in den Figuren wiederholt werden, um entsprechende oder analoge Merkmale anzugeben.
In der folgenden ausführlichen Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der Erfindung bereitzustellen. Dem Fachmann dürfte jedoch klar sein, dass die vorliegende Erfindung auch ohne diese spezifischen Einzelheiten ausgeführt werden kann. In anderen Fällen wurden bekannte Verfahren, Vorgehensweisen und Komponenten nicht ausführlich beschrieben, um die vorliegende Erfindung nicht unklar zu machen.
Es werden ein Verfahren und System beschrieben, bei dem Fehlerereignisse sowohl von einem Hypervisor als auch von den VMs erfasst, normalisiert und einem Fehlerverwaltungssystem zugeführt werden. Auch von dem Hypervisor werden Daten erfasst, die angeben, auf welcher Host-Maschine eine jede VM läuft. Diese Daten werden zur Durchführung der folgenden Aktionen verwendet.

1. Fehlerereignis-Korrelation. Fehlerereignisse, die von der Host-Maschine oder dem Hypervisor (als Host-Ereignisse bezeichnet) sowie der virtuellen Maschine (als VM-Ereignisse bezeichnet) erzeugt werden und die sich auf dasselbe Ursprungsproblem beziehen, werden bestimmt. Das Host-Ereignis, das die Fehler auf den VMs verursacht, erhält einen höheren Schweregrad und wird als eine Ursache gekennzeichnet. Der Schweregrad der entsprechenden Fehler der VMs wird verringert, die Fehler werden als Symptom-Ereignisse gekennzeichnet, und ein Feld in dem Ereignis wird so gesetzt, dass es auf das Ursachen-Ereignis zeigt. Auf diese Weise kann der Bediener die Symptom-Ereignisse sehr viel schneller ausfiltern und das Ursachen-Ereignis mit hohem Schweregrad erkennen. Das Problem lässt sich schneller beheben, wodurch wiederum alle VM-Symptom-Ereignisse bereinigt werden. Wenn der Bediener ein bestimmtes Symptom-Ereignis betrachtet, kann auch die Ursache schnell erkannt werden.
2. Fehlerbehebung nach VM-Verlagerung. Hardwarebezogene Fehler können behoben werden, indem die virtuelle Maschine auf eine neue physische Host-Maschine verschoben wird. Wenn eine VM auf einen neuen physischen Host verlagert wird, wird der Schweregrad aller Fehler dieser Klasse verringert. Nachdem die Überwachungseinheiten auf der VM die Information erhalten, dass der Fehler behoben wurde, werden die VM-Ereignisse bereinigt und als „normal” freigegeben. Der Vorteil dieser Vorgehensweise besteht darin, dass die Bediener-Anzeige sehr viel schneller von Fehlerereignissen mit hohem Schweregrad bereinigt wird, so dass dieser sich auf etwaige andere, wichtigere Probleme konzentrieren kann.

Mit Blick auf 1 wird ein System 100 bereitgestellt, das einen Fehlerverwaltungs-Server 110 für das Verarbeiten von Fehlerereignissen in einer virtuellen Rechnerumgebung beinhaltet.
Die virtuelle Rechnerumgebung beinhaltet eine oder mehrere virtuelle Maschinen 121 bis 126, von denen jede in einem Host-Maschinen-Betriebssystem 131, 132 oder auf Computer-Hardware ausgeführt wird, die eine Software-Schicht aufweist, bei der es sich um eine Überwachungseinheit oder einen Hypervisor 141, 142 einer virtuellen Maschine handelt, die/der Hardware-Ressourcen dynamisch und transparent zuweist. Mehrere Betriebssysteme können gleichzeitig auf einem einzigen physischen Computer ausgeführt werden und Hardware-Ressourcen gemeinsam nutzen. Durch die Kapselung einer vollständigen Maschine mit Zentralprozessor, Speicher, Betriebssystem und Netzwerkeinheiten ist eine virtuelle Maschine 121 bis 126 vollständig kompatibel mit allen standardmäßigen Betriebssystemen, Anwendungen und Einheitentreibern.
Um eine möglichst hohe Auslastung der Host-Maschine zu erzielen und die Fehlertoleranz zu verbessern, werden die VMs 121 bis 126 in einer Gruppe 130 von Host-Maschinen 131, 132 ausgeführt. Wenn eine Host-Maschine 131, 132 ausfällt, können die VMs verschoben (bzw. verlagert) werden, um auf einer anderen Host-Maschine 131, 132 der Gruppe 130 ausgeführt zu werden.
Die VMs 121 bis 126 führen Prüfroutinen aus, um Prüfroutinen-Zuführungen 160 bereitzustellen und dem Fehlerverwaltungs-Server 110 VM-Fehler 161 zu melden, die von einem zugrundeliegenden Hardware-Ausfall oder HardwareProblemen (als VM-Hardware-Fehler bezeichnet) verursacht werden. Die Host-Maschinen 131, 132 können ebenfalls Prüfroutinen ausführen (falls diese durch die Host-Maschinen unterstützt werden), um Prüfroutinen-Zuführungen 170 bereitzustellen und dem Fehlerverwaltungs-Server 110 Host-Hardware-Fehler 171 zu melden.
Der Begriff „Prüfroutine” wird für Programme verwendet, die eine Verbindung zu einer Ereignisqueue wie z. B. einer VM oder Host-Maschine herstellen und Ereignisdaten erkennen, erhalten und anschließend als Warnmeldungen an den Fehlerverwaltungs-Server 110 weiterleiten. Prüfroutinen können die in einer Regeldatei festgelegte Logik verwenden, um die Ereigniselemente zu bearbeiten, bevor sie sie in die Felder einer Warnmeldung in der Warnmeldungsstatus-Tabelle des Fehlerverwaltungs-Servers 110 umwandeln. Jede Prüfroutine ist 50 ausgelegt, dass sie Ereignisdaten von einer spezifischen Quelle erhält. Prüfroutinen können auch als Überwachungseinheiten oder Agenten für das entfernte oder direkte Überwachen von Netzwerkeinheiten bezeichnet werden.
So können z. B. die VMs 121 bis 126 und die Host-Maschinen 131, 132 standardmäßige IBM OMNIbus-Prüfroutinen 160 ausführen, wenn Sie auf Linux^® beruhen oder auf von IBM OMNIbus unterstützten Plattformen laufen (Linux ist eine eingetragene Handelsmarke von Linus Torvalds in den Vereinigten Staaten und/oder anderen Ländern).
Bei einer alternativen Anordnung können die Prüfroutinen auf einer entfernt angeordneten Maschine ausgeführt werden und die Hypervisor-Maschine 131, 132 über ein Netzwerkprotokoll oder mittels Fern-Einbindung (remote mount) überwachen.
Eine Gruppe 130 wird über ein Steuerungszentrum 133 gesteuert und verlagert die VMs 121 bis 126 nach Bedarf auf die Host-Maschinen 131, 132. Das Steuerungszentrum 133 kann auf einer VM 121 bis 126 der Gruppe 130 ausgeführt werden.
Ein Überwachungssystem 150 wird bereitgestellt, das einen Agenten 151 aufweist, der über eine API Daten mit dem Steuerungszentrum 133 austauscht und Situationsereignisse 181 an das Überwachungssystem 150 meldet. Eine Prüfroutine oder Überwachungseinheit wird verwendet, um diese Ereignisse dem Fehlerverwaltungs-Server 110 zuzuführen 180. Die Situationsereignisse 181 verfolgen, welche VM 121 bis 126 sich auf welcher Host-Maschine 131, 132 befindet, und melden darüber hinaus Host-Fehler 171.
Bei einer alternativen Ausführungsform kann der Agent 151 wahlweise anstelle einer Verbindung über das Steuerungszentrum 133 eine direkte Verbindung mit den Hypervisor-Einheiten 141, 142 herstellen, wobei dies jedoch weniger belastbar ist, falls eine vollständige Host-Maschine 131, 132 ausfallen sollte.
Die Host-Hardware-Fehler 171 auf den Hosts 131, 132 werden in den Situationsereignissen 181 über das Steuerungszentrum 133 an das Überwachungssystem 150 und anschließend über die Prüfroutinen-Zuführungen 180, die zur Meldung der Situationsereignisse 181 dienen, an den Fehlerverwaltungs-Server 110 gemeldet.
Wenn die Host-Maschinen 131, 132 Prüfroutinen unterstützen, können die Host-Hardware-Fehler 171 außerdem direkt dem Fehlerverwaltungssystem 110 zugeführt werden. Wenn die Hardware-Fehler 171 dem Fehlerverwaltungssystem über Prüfroutinen direkt zugeführt werden können 170 (in 1 gestrichelt dargestellt), kann mit den Prüfroutinen ein umfassenderer Satz von möglichen Fehlern direkt von den Host-Maschinen 131, 132 erfasst werden.
Der gängigste und am weitesten verbreitete Hypervisor in einer industriellen Umgebung mit hoher Verfügbarkeit ist VMware ESX (VMware und ESX sind Handelsmarken von VMware, Inc.). In einer beispielhaften Ausführungsform kann ein Überwachungssystem in Gestalt von IBM Tivoli Monitor (ITM) mit einem VMware-Agenten für eine virtuelle Infrastruktur (VMware VI Agent) unter Verwendung von VMware-ESX-Hypervisor-Gruppen verwendet werden. Bei dem Fehlerverwaltungs-Server kann es sich um den Objekt-Server (ObjectServer) eines IBM-Netcool/OMNIbus-Systems unter Verwendung von Event-Integration-Facility(EIF)-Prüfroutinen handeln, mit denen Ereignisse von dem VMware VI Agent zugeführt werden.
Die Hardware-Fehler der VMs werden unter Verwendung von IBM-OMNIbus-Prüfroutinen gemeldet. Die VMware-ESX-Hypervisor-Einheiten beruhen auf Linux und können daher standardmäßige IBM-OMNIbus-Prüfroutinen ausführen. Die Hardware-Fehler auf den Hosts werden ebenfalls über das ESX-Steuerungszentrum an ITM und anschließend über die EIF-Prüfroutine an den ObjectServer gemeldet.
Auch andere Hypervisor-Einheiten können verwendet werden, darunter IBM pHYPE, Microsoft^® HyperV^TM (Microsoft und HyperV sind Handelsmarken der Microsoft Corporation in den Vereinigten Staaten und/oder anderen Ländern), Kernel-based Virtual Machine (KVM) unter Linux, z/VM^® (z/VM ist eine eingetragene Handelsmarke der International Business Machines Corporation, die in vielen Rechtsräumen weltweit eingetragen ist) und andere.
Der Überwachungsagent 151 stellt über seine SDK-API eine Verbindung mit dem Steuerungszentrum 133 her und kann die folgenden Situationsereignisse 181 erzeugen. Dabei wird jede Situation ausgelöst, wenn sie auftritt, und aufgehoben, wenn sie nicht mehr zutrifft.
Verfügbarkeit

• Der Zustand des Host-Maschinen-Servers lautet „nicht erreichbar”.

Zentraleinheit (CPU)

• Der VMkernel ist nicht geladen.
• Die CPU-Auslastung ist sehr hoch.
• Die CPU-Auslastung ist gering.
• Die CPU ist überlastet.

Festplatte

• Das Dateisystem ist nahezu voll.
• Die Festplatten-Leseaktivität ist hoch.
• Die Festplatten-Schreibaktivität ist hoch.

Speicher

• Für das Konsolenbetriebssystem (Console OS, COS) steht nur noch wenig freier Speicherplatz zur Verfügung.
• Für den Host-Maschinen-Server steht nur noch wenig freier Speicherplatz zur Verfügung.

Netzwerk

• Die Netzwerk-Sendeaktivität ist hoch.
• Die Netzwerk-Empfangsaktivität ist hoch.

Virtuelle Maschinen

• Die virtuelle Maschine ist abgeschaltet.
• Die virtuelle Maschine befindet sich in einem blockierten Zustand.
• Die virtuelle Maschine befindet sich in einem unbekannten Zustand.
• Die virtuelle Maschine befindet sich in einem angehaltenen Zustand.

Mit Ausnahme von „Der Zustand des Host-Maschinen-Servers lautet ,nicht erreichbar'” hat jede dieser Situationen ein VM-Server-Namensattribut und ein VM-Namensattribut, Dieses entspricht dem Hardware-Server-Namen und dem Namen der VM, die in der Steuerungszentrums-Software konfiguriert sind. Im Normalfall entspricht dies dem Host-Namen der virtuellen Maschine.
Mit Blick auf 2 zeigt ein Blockschaubild einen Fehlerverwaltungs-Server 110. Der Fehlerverwaltungs-Server 110 beinhaltet eine Fehlerereignis-Korrelationskomponente 210 und eine Fehlerbehebungskomponente 220. Zusätzlich beinhaltet der Fehlerverwaltungs-Server 110 eine VM-Zustandstabelle 230 und eine Tabelle der Fehlerereignisse, die als Warnmeldungs-Zustandstabelle 240 für Hardware-Fehler bezeichnet wird.
Die Fehlerereignis-Korrelationskomponente 210 erkennt Fehlerereignisse, die von dem Host oder Hypervisor und der virtuellen Maschine erzeugt werden und sich auf dasselbe Ursprungsproblem beziehen. Das Host-Ereignis, das die Fehler auf den VMs erzeugt, nimmt einen höheren Schweregrad ein und wird als eine Ursache gekennzeichnet. Der Schweregrad der entsprechenden Fehler der VMs wird verringert, die Fehler werden als Symptom-Ereignisse gekennzeichnet, und ein Feld in dem Ereignis wird so gesetzt, dass es auf das Ursachen-Ereignis zeigt.
Die Fehlerbehebungskomponente 220 behebt Fehler nach der VM-Verlagerung. Hardwarebezogene Fehler können behoben werden, indem die virtuelle Maschine auf eine neue physische Host-Maschine verschoben wird. Wenn eine VM auf einen neuen physischen Host verlagert wird, wird der Schweregrad aller Fehler dieser Klasse verringert. Nachdem die Überwachungseinheiten auf der VM die Information erhalten, dass der Fehler behoben wurde, werden die VM-Ereignisse bereinigt und als „normal” freigegeben.
Die VM-Zustandstabelle 230 beinhaltet die Host-Namen der VMs und die Host-Namen des VM-Servers sowie den VM-Zustand.

Eine beispielhafte Ausführungsform der Zustandstabelle 230 des Fehlerverwaltungs-Servers 110 enthält vier Spalten.

Tabelle: custom.vmstatus			Typ: Dauerhaft
Spaltenname	Typ	Größe	Primärer Schlüssel	Anmerkung
VMHostName	varchar	64	Ja
ESXHostName	varchar	64	Nein
VMStatus	Int			0 = offline, 1 = aktiv
StateChange	Time			Letzter Änderungszeitpunkt des Eintrags

Für jedes oben genannte Situationsereignis (mit Ausnahme von „Der Zustand des Host-Maschinen-Servers lautet ,nicht erreichbar'”) sendet die Prüfroutinen-Zuführung das VM-Server- und das VM-Namensattribut an die VM-Zustandstabelle 230 des Fehlerverwaltungs-Servers 110.
Ein erster Auslöser 231 ist der VM-Zustandstabelle zugehörig, um den VM-Zustand entsprechend der Prüfroutinen-Zuführungen zu aktualisieren. Der erste Auslöser 231 der VM-Zustandstabelle 230 wird nicht aktiv, wenn die Daten in der Tabelle unverändert bleiben. Wenn beispielsweise „die virtuelle Maschine ist abgeschaltet”, „die virtuelle Maschine befindet sich in einem blockierten Zustand” oder „die virtuelle Maschine befindet sich in einem angehaltenen Zustand” wahr wird, lautet der Wert der Aktivitätsspalte „0”, andernfalls lautet er „1”.
Bei einer anderen Ausführungsform können Prozeduren aufgerufen werden. Wenn sich z. B. der einer virtuellen Maschine zugehörige Host ändert, wird eine Prozedur „VM_Host_Change” aufgerufen. Wenn sich der Zustand eines VM-Eintrags von „aktiv” zu „inaktiv” ändert, wird eine Prozedur „VM_Down” aufgerufen. Wenn sich der Zustand eines VM-Eintrags von „inaktiv” zu „aktiv” ändert, wird eine Prozedur „VM_Restored” aufgerufen. Die Konfigurationsdateien können anstelle von Prozeduren auch Signale verwenden, die einen anderen Satz von Auslösern aufrufen, um diese Aktionen durchzuführen.
Die VM-Zustandstabelle 230 enthält einen zweiten zeitabhängigen Auslöser 232, der dem Löschen eines VM-Zustandseintrags zugehörig ist. Dieser löscht nicht verwendete Einträge aus der Zustandstabelle 230 und kann einmal täglich ausgeführt werden. Dabei wird jeder Zustandseintrag überprüft, und falls für einen gegebenen Zeitraum (z. B. zwei Wochen) keine Änderung vorliegt, wird der Eintrag gelöscht. Mit diesem Auslöser wird verhindert, dass die VM-Zustandstabelle wächst, wenn regelmäßig vorübergehende virtuelle Abbilder erzeugt und gelöscht werden.
Der Zustand der VM wird durch die von dem Überwachungsagenten bereitgestellten Situationsereignisse 181 auf dem Laufenden gehalten.
Daten werden dupliziert, da verschiedene Situationen der VM-Zustandstabelle 230 unter Umständen dieselben Daten bereitstellen. Auf diese Weise wird ein zusätzliches Maß an Fehlertoleranz für den unwahrscheinlichen Fall bereitgestellt, dass ein Situationsereignis übersehen wird.
Die Überwachung einer Gruppe (VMware-Agent, EIF-Prüfroutine und ObjectServer) sollte bereits laufen, bevor VMs gestartet werden. Dies stellt sicher, dass die VM-Zustandstabelle 230 korrekte Einträge erhält. Wenn zu Beginn der Überwachung bereits VMs in der Gruppe ausgeführt werden, sollten sie angehalten und wieder aktiviert werden, um die VM-Zustandstabelle 230 mit Einträgen zu versehen, oder sie sollten mit VMotion auf einen anderen Host verlagert werden, wenn ein ununterbrochener Dienst benötigt wird.
Eine Prüfroutinen-Regeldatei 260 beinhaltet eine Normalisierungskomponente 261, die eine Abbildung der Situationsereignisse in ein normalisiertes Format vornimmt, das im Einklang mit ähnlichen Fehlerereignissen steht, die von anderen Prüfroutinen erzeugt werden, und dazu dienen kann, Fehlerereignisse und -behebungen für die oben beschriebenen Fehlersituationen einzufügen. Eine Ereigniserzeugungskomponente 262 wird in der Regeldatei 260 dazu verwendet, Ereignisse in die Warnmeldungs-Zustandstabelle 240 und die VM-Zustandstabelle 230 aufzunehmen.
Die Fehlerereignis-Korrelationskomponente 210 stellt eine Beziehung zwischen Hardware-Fehlerereignissen her. Es ist notwendig, Beziehungen zwischen Hardware-Fehlern der virtuellen Maschinen und des Hypervisors herzustellen. Diese Hardware-Fehler 161, 171 werden von Prüfroutinen, die auf den VMs ausgeführt werden, sowie von Prüfroutinen oder Agenten erfasst, die auf dem Hypervisor und/oder den Host-Maschinen ausgeführt werden oder mit diesen Daten austauschen.
Für die VMWare-Beispielkonfiguration werden danach Fehlerereignisse über den ITM-VI-VMware-Agenten fernerfasst.
Nur manche Gruppen von Hardware-Fehlern 161, 171 wirken sich sowohl auf den Hypervisor als auch auf die VMs aus, die darauf ausgeführt werden. Typische Beispiele hierfür sind eine hohe CPU-Auslastung, ein Speicherausfall oder ein Ausfall einer gemeinsam genutzten Einheit. Nur gültige Typen von Hardware-Ereignissen werden verarbeitet. Sie werden von einer Normalisierungskomponente 271, die universelle Fehler in der Prüfroutinen-Regeldatei 270 erkennt, eingestuft und normalisiert. Bei ITM-VMware-Ereignissen erfolgt dies in der EIF-Prüfroutinen-Regeldatei 260.
Nachdem die Fehlerereignisse in die Warnmeldungs-Zustandstabelle 240 eingefügt wurden, wird unter Verwendung eines zeitabhängigen Korrelationsauslösers 241, der in regelmäßigen Abständen, z. B. alle 20 Sekunden, ausgeführt wird, eine Beziehung zwischen ihnen hergestellt.
Sobald eine Beziehung zwischen den Host- und VM-Ereignissen hergestellt wurde, müssen sie geändert werden, um diese Beziehung kenntlich zu machen. Bei einer Ausführungsform werden die VM-Ereignisse 242 als „Symptom”-Ereignisse 243 und die Host-Ereignisse 244 als „Ursachen”-Ereignisse 245 gekennzeichnet. Dabei verweisen die Symptom-Ereignisse auf die Ursachen-Ereignisse.
Wenn eine VM vollständig ausfällt, kann sie auch die Ursache für viele weitere Fehlerereignisse werden. Bei der Ausführungsform, die Prozeduren verwendet, können mit den Prozeduren „VM_Down” und „VM_Restored” Ursachenverknüpfungen mit diesen Fehlertypen hergestellt werden. So kann z. B. eine auf einer VM ausgeführte Prüfroutine ausfallen und einen Fehler erzeugen, da ein Aktivitätssignal nicht mehr empfangen wird. Die Einzelheiten und eine Zusammenfassung des Fehlers werden von der Prozedur „VM_Down” aktualisiert, und die Prozedur „VM_Restored” aktualisiert diese Daten erneut und verringert den Schweregrad des Fehlerereignisses und/oder stellt eine Ursachenverknüpfung her. Der Fehler wird jedoch nur dann bereinigt, wenn die Prüfroutine erneut ausgeführt wird.
Die Fehlerbehebungskomponente 220 behebt Hardware-Fehlerereignisse. Wenn eine VM verlagert wird, aktualisiert sie die VM-Zustandstabelle 230. Diese Prozedur führt eine Überprüfung aller Hardware-Fehlerereignisse durch, die dem VM-Host-Namen zugehörig sind, und verringert ihren Schweregrad, um so anzuzeigen, dass sie nicht länger ein erhebliches Problem darstellen. Wenn eine Ursachenverknüpfung mit einem Ereignis eines physischen Hosts hergestellt wurde, wird sie entfernt.
Diese Hardware-Fehlerereignisse bilden eine Obermenge der Situationsereignisse. Die Fehlerereignisse, die sich sowohl auf den Hypervisor als auch auf die VM auswirken, sollten in ihrem Schweregrad bereits größtenteils verringert worden sein und eine wie auch immer geartete Form von Ursachenverknüpfung aufweisen, die entfernt werden muss. Zudem können auch nicht miteinander in Beziehung stehende Ereignisse vorhanden sein, deren Schweregrad verringert werden muss. Schließlich werden manche Hardware-Fehlerereignisse wie beispielsweise wenig freier Festplatten-Speicherplatz durch das Verlagern der VM nicht behoben und bleiben daher unverändert.
Die vorgeschlagene Lösung beruht auf einer Tabelle 280 für das Abbilden von VM-Host-Name auf Hypervisor-Host-Name. Diese Tabelle 280 wird mit mehreren Auslösern durchsucht. Der primäre Schlüssel ist der VM-Host-Name, der zum Durchsuchen der Tabelle verwendet wird, während der Fehlerverwaltungs-Server eine leistungsfähige Hash-Tabellensuche verwendet. Die höchste Verarbeitungslast entsteht in Zusammenhang mit dem Auslöser 241 für die Herstellung einer Beziehung zwischen VM und physischem Host. Auf diese Weise sollte die Anzahl der Durchläufe durch die Warnmeldungs-Zustandstabelle 240 auf ein Mindestmaß begrenzt bleiben. Wenn ein Hypervisor jedoch ausfällt, könnte eine möglicherweise große Zahl von VMs auf verschiedene Hosts verlagert werden.
Entsprechend könnte, falls ein Hardware-Fehler auf einem Hypervisor auftritt, der viele VMs ausführt, eine möglicherweise große Zahl von Hardware-Fehlerereignissen von den VMs empfangen werden.
Mit Blick auf 3 beinhaltet ein beispielhaftes System für das Realisieren von Aspekten bevorzugter Ausführungsformen der vorliegenden Erfindung ein Datenverarbeitungssystem 300, das für das Speichern und/oder Ausführen von Programmcode geeignet ist und mindestens einen Prozessor 301 enthält, der direkt oder indirekt über ein Bussystem 303 mit Speicherelementen verbunden ist. Zu den Speicherelementen können ein Lokalspeicher, der während der tatsächlichen Ausführung des Programmcodes verwendet wird, ein Massenspeicher und Cachespeicher gehören, die eine vorübergehende Speicherung von mindestens einem Teil des Programmcodes bereitstellen, um die Häufigkeit, mit welcher der Code während der Ausführung aus dem Massenspeicher abgerufen werden muss, zu verringern.
Bei den Speicherelementen kann es sich um einen Systemspeicher 302 in Gestalt eines Festwertspeichers (ROM) 304 und einen Direktzugriffsspeicher (RAM) 305 handeln. Ein grundlegendes Ein/Ausgabe-System (Basic Input/Output System, BIOS) 306 kann im ROM 304 gespeichert sein. System-Software 307 wie z. B. Betriebssystem-Software 308 kann im RAM 305 gespeichert sein. Auch Software-Anwendungen 310 können im RAM 305 gespeichert sein.
Das System 300 kann außerdem ein primäres Speichermittel 311 wie beispielsweise ein magnetisches Festplattenlaufwerk und ein sekundäres Speichermittel 312 wie z. B. ein magnetisches Plattenlaufwerk und ein optisches Plattenlaufwerk beinhalten. Die Laufwerke und ihre zugehörigen computerlesbaren Medien stellen dem System 300 einen nichtflüchtigen Speicher für computerausführbare Befehle, Datenstrukturen, Programm-Module und andere Daten bereit. Software-Anwendungen können auf den primären und sekundären Speichermitteln 311, 312 sowie im Systemspeicher 302 gespeichert sein.
Das Datenverarbeitungssystem 300 kann in einer Netzwerkumgebung betrieben werden, wobei über einen Netzwerkadapter 316 logische Verbindungen zu einem oder mehreren entfernt angeordneten Computern verwendet werden.
Die Ein/Ausgabe-Einheiten 313 können entweder direkt oder über dazwischenliegende E/A-Steuereinheiten mit dem System verbunden sein. Ein Benutzer kann über Eingabe-Einheiten wie eine Tastatur, eine Zeige-Einheit oder andere Eingabe-Einheiten (z. B. Mikrofon, Joystick, Spielekonsole, Satellitenschüssel, Scanner u. ä.) Befehle und Daten in das System 300 eingeben. Zu Ausgabe-Einheiten können Lautsprecher, Drucker usw. zählen. Auch eine Anzeige-Einheit 314 kann über eine Schnittstelle wie z. B. einen Video-Adapter 315 mit dem Systembus 303 verbunden sein.
Mit Blick auf 4 zeigt ein Ablaufplan 400 das beschriebene Verfahren. Situationsereignisse werden empfangen 401 und normalisiert 402. Gleichzeitig werden VM-Prüfroutinen-Ereignisse (und zusätzlich auch Host-Prüfroutinen-Ereignisse, falls diese unterstützt werden) empfangen 403 und normalisiert 404. Die normalisierten Ereignisse werden als Fehlerereignisse in die Warnmeldungs-Zustandstabelle aufgenommen 405.
VM- und Host-Abbildungsdaten werden aus den Situationsereignissen erhalten 406, und die VM-Zustandstabelle wird aktualisiert 407.
Es wird ermittelt, ob sich die VM-zu-Host-Abbildung geändert hat. Wenn sie sich nicht geändert hat, wird lediglich die Eintragszeit aktualisiert 409. Wenn sie sich geändert hat, wird die Eintragszeit aktualisiert, und in der Warnmeldungs-Zustandstabelle werden alle Hardware-Fehler für die verschobene VM gesucht 410.
Danach wird ermittelt 411, ob in Frage kommende Hardware-Fehler für die VM vorhanden sind. Wenn nein, endet das Verfahren 412. Wenn ja, wird der Schweregrad der VM-Fehler verringert 413 und eine Symptomeinstufung, falls vorhanden, entfernt. Sofern vorhanden, wird die Verknüpfung mit dem Host-Ursachenfehler aufgelöst. Das Verfahren endet dann 414.
Mit Blick auf 5 zeigt ein Ablaufplan 500 ein Verfahren für die Herstellung einer Beziehung zwischen Fehlern, das in regelmäßigen Abständen durchgeführt wird.
Zunächst werden Fehler, die für eine VM-Korrelation in Frage kommen, bestimmt 501. Hierfür werden alle Fehler in der Warnmeldungs-Zustandstabelle gesucht, die folgende Bedingungen erfüllen:

• sie wurden nicht als Ursache oder Symptome eingestuft;
• sie wurden nicht bereits behoben;
• sie haben einen Host-Namen, der mit einem der VM-Host-Namen in der VM-Zustandstabelle übereinstimmt; und
• sie gehören zu einem Typ, der durch ein Host-Problem verursacht werden könnte.

Es wird ermittelt 502, ob in Frage kommende Fehler gefunden werden. Wenn nein, endet das Verfahren 503. Wenn derartige Fehler vorhanden sind, wird für jeden Fehler, der für eine VM-Korrelation in Frage kommt, der Host-Server-Name in der VM-Zustandstabelle gesucht 504. Alle Host-Server-Namen werden als Satz von Host-Server-Namen erfasst 505.
Danach werden Fehler bestimmt 506, die für eine Host-Korrelation in Frage kommen. Hierfür werden alle Fehler in der Warnmeldungs-Zustandstabelle gesucht, die folgende Bedingungen erfüllen:

• sie wurden nicht als Symptome eingestuft;
• sie wurden nicht bereits behoben;
• sie haben einen Host-Namen aus dem Satz von Host-Server-Namen aus Schritt 505; und
• sie gehören zu einem Typ, der ein Host-Problem verursachen könnte.

Es wird ermittelt 507, ob in Frage kommende Fehler gefunden werden. Wenn nein, endet das Verfahren 508. Wenn derartige Fehler vorhanden sind, wird für jeden Fehler, der für eine VM-Korrelation in Frage kommt, der Host-Fehler unter den für eine Host-Korrelation in Frage kommenden Fehlern gesucht 509.
Es wird ermittelt 510, ob der Fehlertyp übereinstimmt. Wenn nein, endet das Verfahren 511. Wenn er übereinstimmt, gibt es ein Paar von korrelierten VM- und Host-Fehlern 512.
Der VM-Fehler wird als Symptom gekennzeichnet 513, das Feld „local root object” (lokales Ursachenobjekt) zeigt auf den Host-Fehler, und der Schweregrad des Fehlers wird verringert. Der Host-Fehler wird als Ursache gekennzeichnet 514, und sein Schweregrad wird erhöht.
Dabei ist zu erwähnen, dass mehrere VM-Fehler auf einen einzigen Host-Ursachenfehler zeigen können.
Ein Fehlerverwaltungssystem kann einem Kunden über ein Netzwerk als Dienst bereitgestellt werden.
Die Erfindung kann in Gestalt einer vollständig in Hardware realisierten Ausführungsform, einer vollständig in Software realisierten Ausführungsform oder einer Ausführungsform vorliegen, die sowohl Hardware- als auch Software-Elemente enthält. Bei einer bevorzugten Ausführungsform wird die Erfindung in Software-Form realisiert, darunter, ohne auf diese beschränkt zu sein, Firmware, speicherresidente Software, Mikrocode usw.
Die Erfindung kann in Gestalt eines Computerprogrammprodukts vorliegen, auf das über ein computernutzbares oder computerlesbares Medium zugegriffen werden kann, das Programmcode bereitstellt, der durch oder in Verbindung mit einem Computer oder einem beliebigen anderen System zur Befehlsausführung verwendet werden kann. Zum Zwecke dieser Beschreibung kann ein computernutzbares oder computerlesbares Medium jedwede Vorrichtung sein, die das Programm, welches durch oder in Verbindung mit dem Befehlsausführungssystem, der Vorrichtung oder Einheit verwendet wird, enthalten, speichern, austauschen, verteilen oder übertragen kann.
Das Medium kann ein elektrisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem (oder eine entsprechende Vorrichtung bzw. Einheit) oder ein Verteilungsmedium sein. Zu Beispielen für ein computerlesbares Medium zählen ein Halbleiter- oder Festkörperspeicher, ein Magnetband, eine wechselbare Computerdiskette, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), eine magnetische Festplatte und eine optische Festplatte. Gegenwärtige Beispiele für optische Festplatten sind Compact Disk Read Only Memory (CD-ROM), Compact Disk Read/Write (CD-R/W) und DVD.
An den obigen Ausführungen können Verbesserungen und Änderungen vorgenommen werden, ohne vom Geltungsumfang der vorliegenden Erfindung abzuweichen.

Claims

Verfahren für die Fehlerverwaltung in virtuellen Rechnerumgebungen, das Folgendes umfasst: Überwachen von Fehlerereignissen (401, 403) virtueller Maschinen (121 bis 126) und Host-Einheiten (131, 132) in einer virtuellen Rechnerumgebung; Überwachen von Situationsereignissen (401) in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse (401) auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen; Ermitteln (501 bis 512), ob ein Fehlerereignis sowohl virtuelle Maschinen (121 bis 126) als auch Host-Einheiten (131, 132) betrifft; Herstellen einer Beziehung (512) zwischen Fehlerereignissen, die sich auf virtuelle Maschinen (121 bis 126) und Host-Einheiten (131, 132) beziehen, als zu demselben Problem gehörig.
Verfahren nach Anspruch 1, das Folgendes aufweist: Pflegen (407) einer Tabelle zum Zustand virtueller Maschinen (230); und Pflegen einer Abbildung (250) von Namen virtueller Maschinen und von Namen von Host-Einheiten.
Verfahren nach Anspruch 1 oder 2, das Folgendes aufweist: Einfügen (405) von Fehlerereignissen in eine Tabelle für Fehlerereignisse (240).
Verfahren nach Anspruch 3, wobei Host-Maschinen-Fehlerereignisse, die in Beziehung zu einem Problem stehen, in der Tabelle der Fehlerereignisse (240) als ein Ursachen-Ereignis gekennzeichnet werden (514).
Verfahren nach Anspruch 3 oder Anspruch 4, wobei Fehlerereignisse von virtuellen Maschinen, die in Beziehung zu einem Problem stehen, in der Tabelle der Fehlerereignisse als Symptome gekennzeichnet werden (513) und eine Verknüpfung zu dem Ursachen-Ereignis in die Tabelle der Fehlerereignisse aufgenommen wird.
Verfahren nach einem beliebigen der vorhergehenden Ansprüche, wobei, wenn eine virtuelle Maschine (121 bis 126) auf eine neue Host-Maschine (131, 132) verschoben wird, alle Fehlerereignisse der virtuellen Maschine in der Tabelle der Fehlerereignisse aufgefunden werden und ihr Schweregrad verringert wird (413).
Verfahren nach Anspruch 6, wobei eine Ursachenverknüpfung entfernt wird (413).
Verfahren nach einem beliebigen der vorhergehenden Ansprüche, wobei die Situationsereignisse (181) durch ein Überwachungssystem (150) überwacht werden, von dem eine Prüfroutine Ereigniswarnmeldungen (180) zuführt, und eine Angabe zu Beziehungen zwischen einer virtuellen Maschine (121 bis 126) und einer Host-Einheit (131, 132) und Host-Fehlerereignissen (171) beinhalten.
Verfahren nach einem beliebigen der vorhergehenden Ansprüche, wobei die Fehlerereignisse (161) in den virtuellen Maschinen durch Prüfroutinen zugeführt werden (160), die auf den virtuellen Maschinen (121–126) ausgeführt werden.
Verfahren nach einem beliebigen der vorhergehenden Ansprüche, wobei die Fehlerereignisse (171) in den Host-Maschinen durch Prüfroutinen zugeführt werden (170), die auf den virtuellen Maschinen (131, 132) ausgeführt werden.
Verfahren nach einem beliebigen der vorhergehenden Ansprüche, wobei die Fehlerereignisse (171) in den Host-Maschinen durch ein Überwachungssystem (150) überwacht werden, von dem eine Prüfroutine Ereigniswarnmeldungen zuführt (180).
Computer-Software-Produkt für die Fehlerverwaltung in virtuellen Rechnerumgebungen, wobei das Produkt ein computerlesbares Speichermedium umfasst, das einen Computer speichert, in dem durch einen Computer ausführbare Befehle gespeichert sind, wobei die Befehle, wenn sie durch einen Computer gelesen und ausgeführt werden, die folgenden Schritte durchführen: Überwachen von Fehlerereignissen (401, 403) von virtuellen Maschinen (121 bis 126) und Host-Einheiten (131, 132) in einer virtuellen Rechnerumgebung; Überwachen von Situationsereignissen (401) in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse (401) auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen; Ermitteln (501 bis 512), ob ein Fehlerereignis sowohl virtuelle Maschinen (121 bis 126) als auch Host-Einheiten (131, 132) betrifft; Herstellen einer Beziehung (512) zwischen Fehlerereignissen, die sich auf virtuelle Maschinen (121 bis 126) und Host-Einheiten (131, 132) beziehen, als zu demselben Problem gehörig.
System für eine Fehlerverwaltung in virtuellen Rechnerumgebungen, das Folgendes aufweist: einen Prozessor; eine Überwachungseinheit (160, 170) für Fehlerereignisse (161, 171) virtueller Maschinen (121 bis 126) und Host-Einheiten (131, 132) in einer virtuellen Rechnerumgebung; eine Überwachungseinheit (150) für Situationsereignisse (181) in der virtuellen Rechnerumgebung, wobei sich die Situationsereignisse (181) auf einen Namen einer virtuellen Maschine und einen Namen einer Host-Einheit beziehen; eine Normalisierungskomponente (271, 261), um zu ermitteln, ob ein Fehlerereignis (161, 171) sowohl virtuelle Maschinen (121 bis 26) als auch Host-Einheiten (131, 132) betrifft; und eine Korrelierungskomponente (210) für ein Herstellen einer Beziehung zwischen Fehlerereignissen (161, 171), die sich auf virtuelle Maschinen und Host-Einheiten beziehen, als zu demselben Problem gehörig.
System nach Anspruch 13, das Folgendes aufweist: eine Tabelle zum Zustand virtueller Maschinen (230) und eine Abbildung (250) von Namen virtueller Maschinen und Namen von Host-Einheiten.
System nach Anspruch 13 oder Anspruch 14, das Folgendes aufweist: eine Tabelle für Fehlerereignisse (240) für ein Pflegen einer Liste von Fehlerereignissen, die sich auf virtuelle Maschinen (121–126) oder Host-Einheiten (131, 132) beziehen.
System nach Anspruch 15, das in der Tabelle der Fehlerereignisse (240) eine Ursachen-Ereignis-Kennzeichnung (243) für Host-Maschinen-Fehlerereignisse aufweist, die in Beziehung zu einem Problem stehen.
System nach Anspruch 15 oder Anspruch 16, das in der Tabelle der Fehlerereignisse (240) eine Symptom-Kennzeichnung (245) für Fehlerereignisse virtueller Maschinen, die in Beziehung zu einem Problem stehen, und eine Verknüpfung (246) zu dem Ursachen-Ereignis in der Tabelle der Fehlerereignisse (240) aufweist.
System nach einem beliebigen der Ansprüche 13 bis 17, das eine Fehlerbehebungskomponente (220) aufweist, wobei, wenn eine virtuelle Maschine (121 bis 126) auf eine neue Host-Maschine (131, 132) verschoben wird, die Behebungskomponente (220) alle Fehlerereignisse der virtuellen Maschine in der Tabelle der Fehlerereignisse (240) auffindet und den Schweregrad der Ereignisse verringert.
System nach einem beliebigen der Ansprüche 13 bis 18, wobei die Überwachungseinheit (150) für Situationsereignisse (181) die Situationsereignisse von einem Steuerungszentrum der virtuellen Umgebungsgruppe (133) erhält und dem Fehlerverwaltungssystem (110) Ereigniswarnmeldungen (180) zuführt.
System nach einem beliebigen der Ansprüche 13 bis 19, wobei die Überwachungseinheit für Fehlerereignisse aus Prüfroutinen (160) besteht, die auf den virtuellen Maschinen (121 bis 126) ausgeführt werden.
System nach einem beliebigen der Ansprüche 13 bis 20, wobei die Überwachungseinheit für Fehlerereignisse aus Prüfroutinen (170) besteht, die auf den Host-Maschinen (131, 132) ausgeführt werden.
System nach einem beliebigen der Ansprüche 13 bis 21, wobei die Überwachungseinheit (150) für Fehlerereignisse (171) in den Host-Maschinen (131, 132) die Fehlerereignisse (171) von einem Steuerungszentrum einer virtuellen Umgebungsgruppe (133) erhält und dem Fehlerverwaltungssystem (110) Ereigniswarnmeldungen (180) zuführt.
System nach Anspruch 21, wobei die Prüfroutinen (170) auf einer entfernt angeordneten Maschine ausgeführt werden und die Host-Maschine (131, 132) über ein Netzwerk überwachen.
Computerprogramm, das auf einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers ladbar ist, welches Softwarecode-Teile umfasst, die, wenn das Programm auf einem Computer ausgeführt wird, das Verfahren nach einem beliebigen der Ansprüche 1 bis 11 durchführen.