Veeam: „Unable to release guest. Details: VSSControl: Failed to freeze guest, wait timeout“

Problem

Ab und zu werden Sicherungen in Veeam Backup and Replication mit dem Fehler „Unable to release guest. Details: VSSControl: Failed to freeze guest, wait timeout“ (Error: Mindestens ein Fehler ist aufgetreten.) abgeschlossen. Es tritt aber sonst kein Fehle auf, alle Snapshots werden korrekt zurückgerollt und die Sicherung ist auch intakt.

Lösung

Das Timeout von standarmäßig 900 Sekunden (15 Minuten) für das VSS-Freeze reicht je nach I/O Aktivität für manche Gäste nicht aus. Man kann das Timout aber problemlos (auf bis zu 30 Minuten) erhöhen. die Angabe in dem Schlüssel ist in Millisekunden.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Veeam\Veeam Backup and Replication
REG_DWORD (32bit): VssPreparationTimeout
Wert: 1b7740 (hex, = 1800000 dec = 30 Minuten)

Für ältere 32bit-Systeme:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
REG_DWORD (32bit): VssPreparationTimeout
Wert: 1b7740 (hex, = 1800000 dec = 30 Minuten)

Dann die Dienst(e) neu starten, fertig. Wenn das noch nicht ausreicht, gibt es offensichtlich irgendwo ein I/O-Problem; mehr als 30 Minuten für einen konsistenten Disk-State sind definitiv zu viel.

Zugehöriger Veeam-KB-Artikel: https://www.veeam.com/de/kb1377

vSphere erzeugt beim Snapshots-Erstellen NTFS-Fehler auf Windows-Servern (Event 50/57/137 …)

Problem

ntfs-fehler-event-55Das Erstellen eines oder mehrere Snapshots, zum Beispiel durch Backupsoftware (Veeam, R2Data, Tivoli …) erzeugt Fehler und Warnungen im Eventlog des Windows-Servers:

  • ID 50 NTFS Warning, delayed write failed / delayed write lost
  • ID 55 NTFS Fehler, In der Dateisystemstruktur wurde eine Fehler erkannt
  • ID 57 NTFS Warning, failed to flush data to the transaction log. Courruption may occur.
  • ID 137, NTFS Error, The default transaction resource manager on volume [] encountered a non-retryable error
  • ID 140, NTFS Warning, failed to flush data to the transaction log. Courruption may occur in VolumeID:
  • ID 12289 VSS Error, Volume Shadow Copy Service error: Unexpected error DeviceIOControl

Je nach Umstand können sogar echte Daten verloren gehen (unter Umständen sogar eine korrupte Datenbank). Die vmware-Version (vSphere 4/5/6, vRealize …) ist dabei irrelevant.

Lösung

Der Fehler liegt eigentlich am Windows Server und ist Microsoft bekannt (http://kb.vmware.com/kb/20068499). Eine Hotfix-Lösung gibt es leider (noch) nicht, aber bevor man mit defekten Daten hantiert und diese am Ende noch kaputt sichert, sollte man bei den betroffenen Systemen auf die quiescence verzichten:

  • Config-Datei für die vmware Tools bearbeiten (oder erstellen, wenn nicht vorhanden)
    C:\ProgramData\VMware\VMware Tools\Tools.conf
  • Diese Zeilen einfügen:
    [vmbackup]
    vss.disableAppQuiescing = true
    
  • Dann den vmware Tools-Dienst neu starten

Und schon laufen externe Snapshots ohne Quiescence auf diesem System. Hoffentlich wird das bald gefixt …

vmware vSphere/ESX(i) Gast wird grau und „(ungültig)“ im Inventory angezeigt

Problem

vmware-ungueltig-ungueltig
Der Name wir kursiv aber korrekt angezeigt, dahinter steht (ungültig)

Nachdem Dinge mit einem Datastore geschehen sind (Datastore umbenennen, neue ID, verschieben …), kann es passieren, das virtuelle Maschinen nur noch kursiv, grau und mit dem Zusatz „(ungültig)“ im Inventory auftauchen. Man kann mit diesen Gästen im vSphere Client nichts mehr anfangen. Zudem gibt es in den Aufgaben und Ereignissen des Gastes einen Eintrag „… verursachte einen Fehler“.

vmware-ungueltig

Lösung

MIn der Regel reicht es, die Maschine aus dem Arbeitsspeicher des zugehörigen ESX-Hosts zu töten und die .VMX der Maschine neu zu laden.

  1. SSH auf dem ESX-Host aktivieren (Tab Konfiguration > Sicherheitsprofil > Dienste, oben rechts auf „Eigenschaften“ -> SSH -> Starten)
  2. PID der Virtuelle Maschine finden
    ~ # ps | grep vmx |grep MASCHINE
    40357 40352 vmx-vthread-4:MASCHINE /bin/vmx
    40358 40352 vmx-vthread-5:SERVER01 /bin/vmx
    40359 40352 vmx-mks:SEREVR13 /bin/vmx
    40360 40352 vmx-svga:SERVER198 /bin/vmx
    

    Das rote ist die PID der virtuellen Maschine.

  3. Virtuelle Maschine hart beenden
    ~ # kill -9 <PID>
  4. Inventory ID (Vmid) der virtuellen Maschine finden
    ~ # vim-cmd vmsvc/getallvms |grep MASCHINE
    22          MASCHINE     [vol1] CBHDC/CBHDC.vmx        windows8Server64Guest   vmx-08
    36      MASCHINE4    [vol1] CBHDC1/CBHDC1.vmx      winNetStandardGuest     vmx-07
    
  5. VMX der Maschine neu laden
    ~ # vim-cmd vmsvc/reload Vmid

DAs war schon alles, nach ein paar Sekunden (2-3) tauscht die Maschine wieder lauffähig auf. Wenn es immer noch einen Fehler gibt, loht ein Blick in die .VMX Datei des Gastes, eventuell sind ja Datastore-Pfade verwaist und müssen auf den richtigen Link umgebogen werden.

vmware Tools 10: Alles neu, neue Downloads, neues System

vmware wagt mit der nagelneuen Version 10 der vmware Tools einen ungewohnt großen Schritt. Ab jetzt sind die Releases der vmware Tools nicht mehr an eine bestimmte ESX/ESXi Version gebunden, sonden existieren frei in einem eigenen Versionsuniversum. Technisch bringt das ein paar gute Neuigkeiten mit: endlich kein Versionschaos mehr.

Good news. We have decided that there isn’t any specific reason that VMware Tools builds should be tied to vSphere releases/ESXi builds

Endlich nur noch EINE Release ausprobieren, Release Notes lesen und zentral aktualisieren. Wir finden, das ist ein guter Plan.

Auf der anderen Seite sind wir auf den zusätzlichen Aufwand gespannt, vorher stabil laufende ESX- und Tools-Kombinationen nun erneut testen zu müssen … nunja, der Fortschritt.

Leider sind die neuen Versionen noch nicht auf den bekannten FTP-Servern angekommen, daher gibt es (bisher) nur die umständlichen Weblinks. Direkte links liefern wir selbstverständlich bald nach.

Die neuen Releases sind jetzt auch direkt via FTP erreichbar:

Was gibt’s neues in den vmware Tools 10

Um es kurz zu machen: nicht viel. Die meisten Neuigkeiten betreffen internas der Tools und die (längst überfällige) Zusammenarbeit mit Linux (in 4er Kernelzweigen).

  • Common versioning: Infrastructure changes to enable reporting of true versions for VMware Tools Operating System Specific Packages.
  • Common Agent Framework: Common Agent Framework (CAF) provides the basic services necessary to simplify secure and efficient management of agents inside the guest virtual machines.
  • Quiesced snapshots enhancements on Linux: vmtoolsd service supports caching of log messages when guest I/O has been quiesced. Enhancements in vmbackup plug in to use a separate thread to quiesce the guest operating system to avoid timeout issues due to heavy I/O in the guest.
  • Shared folders: For Linux distributions with kernel version 4.0.0 and higher, there is a new FUSE  based Shared Folders client which is used as a replacement for the kernel mode client.
  • ESXi serviceability: Default vmtoolsd logging is directed to a file instead of Syslog or Event Viewer.
  • GuestInfo enhancements: Plug in enhancements to report more than 64 IP addresses from the guest.

vCenter Anmeldung mit Domänenkonto (DomainNotFoundExceptionE)

Problem

Nach hinzufügen des vCenter zum AD zeigt die Anmeldung mit einem Domänenkonto eine Fehlermeldung (DomainNotFoundExceptionE, Domain Not Found Exception, No Domain found with ID <Domainname>, N3Vpx6common3Sso23DomainNotFoundExceptionE)

Lösung

Das AD muss als SSO Authentifizierungsquelle hinzugefügt werden:

  1. vSphere Web Client installieren (aus der vCenter Server iso)
  2. im vSphere Web Client die Domäne als SSO Authentifizierungsquelle hinzufügen
    • Am Web Client anmelden ([email protected])
    • Im linken Bereich den Menüpunkt „Verwaltung“ aufrufen
    • Die „Single Sign On -> Konfiguration“ aufrufen
    • Über das „+“-Zeichen das Fenster zum Hinzufügen von Authentifizierungsquellen öffnen
    • Als Typ der Authentifizierungsquelle „Active Directory (Integrierte Windows-Authentifizierung)“ auswählen
    • Den Domänennamen eingeben und „Maschinenkonto verwenden“ ausgewählt lassen
    • Mit „OK“ bestätigen und vom Web Client abmelden
  3. im vSphere Client unter Berechtigungen -> Berechtigungen hinzufügen die gewünschten Benutzer/Gruppen hinzufügen und Rolle auswählen