Sie befinden sich hier: Fehlerbehebung > Infos zu Virtual Standby > Virtual Standby-Jobs schlagen aufgrund interner Fehler fehl

Virtual Standby-Jobs schlagen aufgrund interner Fehler fehl

Gilt für Windows-Betriebssysteme.

Symptom 1:

Virtual Standby-Jobs schlagen fehl. Es wird eine der folgenden Meldungen im Aktivitätsprotokoll angezeigt:

Fehler beim Konvertieren des virtuellen Datenträgers.

Ein interner Fehler ist aufgetreten. Setzen Sie sich mit CA Support in Verbindung.

Außerdem wird im VDDK die folgende Fehlermeldung angezeigt:

Unbekannter Fehler.

Lösung 1:

Um dieses Problem zu beheben, beachten Sie folgende Lösungsmöglichkeiten:

Konvertierungsvorgänge können fehlschlagen, wenn im Datenspeicher, der in der Virtual Standby-Richtlinie angegeben ist, nicht genügend freier Speicherplatz vorhanden ist. VDDK gibt die Meldung zurück, da die VDDK-API es (derzeit) nicht unterstützt, die Größe des freien Speicherplatzes im Datenspeicher zu erkennen. Um dieses Problem zu beheben, machen Sie im ursprünglichen Datenspeicher so viel Festplattenspeicher frei, wie für den Abschluss des Vorgangs erforderlich ist, und übergeben Sie den Job erneut.

Netzwerkstörungen und starker Netzwerkverkehr können dazu führen, dass die Konvertierung fehlschlägt. Um dieses Problem zu beheben, stellen Sie sicher, dass der Quellknoten über das Netzwerk mit dem ESX Server- bzw. vCenter-System kommunizieren kann, und übergeben Sie den Job erneut.
Wenn mehrere gleichzeitige Verbindungen vorliegen, die aus Jobs zur Sicherung oder Wiederherstellung von virtuellen Rechnern auf dem ESX Server- oder vCenter Server-System bestehen - wobei Verbindungen über den VMware vSphere Client stattfinden - schlagen diese Jobs möglicherweise fehl. Um dieses Problem zu beheben, beenden Sie alle unnötigen Verbindungen, und übergeben Sie den Job erneut.
Dieses Problem hat seine Ursache in einer Verbindungsbeschränkung in VMware-VDDK. Folgende Protokollbeschränkungen der Netzwerkdateikopie (NFC) gelten für:

ESXi 5: Von einem Übertragungspuffer für alle NFC-Verbindungen beschränkt und vom Host erzwungen; die Summe aller NFC-Verbindungpuffer zu einem ESXi-Host darf 32 MB nicht überschreiten. 52 Verbindungen durch vCenter Server einschließlich der Grenze pro Host.

Hinweis: Verbindungen können nicht über Festplatten hinweg gemeinsam genutzt werden. Die Werte für "Maximale Beschränkungen" beziehen sich nicht auf SAN- oder HotAdd-Verbindungen. Wenn der NFC-Client nicht ordnungsgemäß heruntergefahren wird, können Verbindungen für zehn Minuten offen bleiben.

Prüfen Sie die Abschnitte "Tasks" (Aufgaben) und "Events" (Ereignisse) des VMware vSphere Client-Protokolls, um interne Fehler beim spezifischen virtuellen Rechner zu entdecken. Beheben Sie die internen Fehler, und übergeben Sie den Job erneut.
Beispiel: Eine andere Anwendung bzw. ein anderer Vorgang verwendet die VMDK-Datei. Um dieses Problem zu beheben, geben Sie die Datei frei, und übergeben Sie den Job erneut.

Symptom 2:

Virtual Standby-Jobs schlagen fehl. Es wird eine der folgenden Meldungen im Aktivitätsprotokoll angezeigt:

Fehler beim Konvertieren des virtuellen Datenträgers.

Ein interner Fehler ist aufgetreten. Setzen Sie sich mit CA Support in Verbindung.

Außerdem wird im VDDK die folgende Fehlermeldung angezeigt:

Open vmdk failed with error File not found. (Öffnen von vmdk fehlgeschlagen, Datei nicht gefunden)

Lösung 2:

Dieses Problem kann unter folgenden Umständen auftreten:

In VDDK wurde ein Snapshot nicht richtig bearbeitet.
In VDDK wurde ein Snapshot nicht manuell oder nicht vom virtuellen Rechner entfernt.

Um dieses Problem zu beheben, übergeben Sie den Job erneut. Wenn der Job erneut fehlschlägt, löschen Sie den wiederhergestellten virtuellen Rechner, und übergeben Sie den Job erneut.

Symptom 3:

Virtual Standby-Jobs schlagen fehl. Es wird eine der folgenden Meldungen im Aktivitätsprotokoll angezeigt:

'<Planname>' kann nicht auf den Knoten '<Knotenname>' angewendet werden. Der Arcserve UDP Agent-Webdienst auf dem Konverter "<Konvertername>" ist ausgelastet. Versuchen Sie es später erneut.

Außerdem wird in der Protokolldatei der UDP-Konsole (ARCApp.log) die folgende Fehlermeldung angezeigt:

[FEHLER] deployVsbTask: Fehler beim Aufrufen der D2D-Webdienst-API - Zeitüberschreitung. javax.xml.ws.WebServiceException: java.net.SocketTimeoutException: Zeitüberschreitung beim Lesen

Lösung 3:

Dieses Problem kann aufgrund einer Zeitüberschreitung auftreten. Gehen Sie folgendermaßen vor, um das Problem zu beheben:

Melden Sie sich bei der UDP-Konsole mit den entsprechenden Anmeldeinformationen an.
Öffnen Sie die Befehlszeilenschnittstelle und führen Sie den folgenden Befehl aus:
regedit
Die Registrierung wird angezeigt.
Navigieren Sie zu \SOFTWARE\Arcserve\Unified Data Protection\Engine\WebService.
Stellen Sie sicher, dass der Schlüssel timeoutValue vorhanden ist. Wenn der Schlüssel nicht vorhanden ist, erstellen Sie ihn manuell.
Sie können den neuen Schlüssel wie unten aufgeführt hinzufügen/ändern:
- Schlüsselname: timeoutValue
1. Wert: <Geben Sie den Wert in Minuten ein>. Wenn Sie z. B. den Wert für die Zeitüberschreitung auf 20 Minuten festlegen möchten, geben Sie den Wert "20" an.
Beenden Sie regedit.
Navigieren Sie zum Installationsordner der UDP-Konsole. Beispiel: C:\Programme\Arcserve\Unified Data Protection\Management\Configuration.
Öffnen Sie die Datei ConsoleConfiguration.xml im Editor.
Suchen Sie im Abschnitt <TimeoutConf> den folgenden Text:
<webServiceRequestTimeout>600</webServiceRequestTimeout>
Ändern Sie den Wert von webServiceRequestTimeout in Sekunden. Wenn Sie z. B. den Wert für die Zeitüberschreitung auf 20 Minuten festlegen möchten, geben Sie den Wert "1200" an.
Speichern Sie die Konfigurationsdatei und beenden Sie den Editor.
Starten Sie den UDP-Konsolen-Verwaltungsdienst neu, damit die Einstellungen wirksam werden.
Stellen Sie den Plan erneut bereit und überprüfen Sie die Ergebnisse.