VMware ESX 6.0 Host UI funktioniert nicht „503 Service Unavailable“

Problem

Nach dem Update von vSphere 5.x auf 6.0 funktioniert das coole neue Webbaierte Host-UI nicht. Stattdessen erscheint die Fehlermeldung:

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http16LocalServiceSpecE:0xffa014e8] _serverNamespace = /ui _isRedirect = false _port = 8308)

Lösung

  1. SSH auf dem betroffenen Host aktivieren, einloggen
  2. ein Backup der Reverse-Proxy Config endpoints.conf erstellen
    # cp /etc/vmware/rhttpproxy/endpoints.conf /etc/vmware/rhttpproxy/endpoints.conf.backup
  3. die Datei /etc/vmware/rhttpproxy/endpoints.conf bearbeiten
    # vi /etc/vmware/rhttpproxy/endpoints.conf
  4. Diese Zeile entfernen (in vi durch drücken von d+d in der Zeile):
    /ui    local    8308    redirect    allow
  5. Die rhttpproxy-Dienste neu starten:
    # /etc/init.d/rhttpproxy restart
  6. Fertig. Jetzt klappt der Zugang über https://<ip>/ui wieder.

VMWare vCenter Appliance (VCSA) hängt beim booten bei „Starting VMware Log Browser“

Problem

Eine VCSA5 (VMWare vCenter Appliance 5.5*) startet nicht sauber neu und hängt beim booten bei der Meldung „Starting VMWare Log Browser“. Die VPX-Dineste der Appliance kommen nicht hoch, das vCenter ist nicht zu gebrauchen.

Lösung

Per SSH auf die Maschine und alle Dateien sowie Ordner (und enhaltene Dateien) aus /var/log/vmware/logbrowser/ löschen. Reboot, fertig.

vSphere: Black Screen bei Installation von SLES 12 oder RHEL 7.x Linux, Kernel-Dump unter RHEL 7.x

Problem

Bei der Installation von SLES 12 oder RHEL 7.4 tritt ein Blackscreen auf, die Installation geht nicht weiter.

Nach der Migration (oder Upload) von einem fertig installierten RHEL 7.4x gibt es nach dem einschalten einen Kernel-Dump und die Maschine bleibt stehen.

Lösung

Das passiert nur beim Einsatz der Intel E1000 Netzwerkkarte in der VM. Tauscht man die Karte gegen einen VMXNET-Adapter klappt alles. Wenn man den Kernel-Dump zerpflückt, sieht man im Call trace einen Reset der E1000 Karte.

Update: Nach unserem Case dazu hat vmware ein Update für den Host herausgebracht:

This issue is resolved in:

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 …