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.

Skype Installation „Fehler 2 – Datei nicht gefunden“

Beim Skype-Update oder bei einer Skype-Neuinstallation schliesst sich das Setup schon mal mit der nichtssagenden „Fehlermeldung 2 – Datei nicht gefunden“.

Die Lösug ist einfach: Das Sykpe-Setup starten und wärend des Installationsvorganges den Temp-Ordner (%appdata%\..\local\temp) überwachen. Dort wird eine „skype.msi“ entpackt. Diese einfach wegkopieren, denn das Setup löscht diese nach dem Fehlschlag wieder.

Tritt die Fehlermeldung auf, das Setup beenden und Skype mittels dieser MSI-Datei installieren – fertig.

psexec „Das System kann die angegebene Datei nicht finden.“

Problem

Warum funktioniert PSEXEC (aus den Sysinternal tools) scheinbar sporadisch nicht? Zum Beispiel funktioniert der Befehl:

psexec \\SERVER net start <FOOBAR>

fehlerfrei, aber dieser Befehl hingegen

psexec \\SERVER rd /Q /S <C:\FOOBAR>

funktioniert nicht und gibt die scheinbar sinnlose Fehlermeldung „Das System kann die angegebene Datei nicht finden.“ zurück.

Lösung

PSEXEC führt im Standardfall nur Prozesse aus. „net“ ist ein normales Programm (net.exe), also ein Startbarer Prozess. „rd“ hingegen, wie auch „dir“, „type“, „find“ und so weiter sind keine externen Programme, sondern Befehle der Shell, also Kommandos des Prozesses CMD. Um diese auszuführen, muss man also eine CMD-Shell via PSEXEC starten und dieser Shell dann die Kommandos übergeben.

Das Beispiel funktioniert fehlerfrei so:

psexec \\SERVER cmd /c rd /Q /S <C:\FOOBAR>

Der Parameter „/c“ für CMD.EXE Führt den Befehl in der Eingabe einfach aus und endet dann.

Firefox zeigt keine SSL-Seiten an mit dem Fehler „ssl_error_weak_server_ephemeral_dh_key“

Problem

firefox_ssl_error_weak_server_ephemeral_dh_keyFirefox ab Version 39 zeigt viele SSL-gesicherte Seiten nicht mehr an und gängelt den erfahrenen Admin stattdessen mit dieser Meldung:

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit foo.bar aufgetreten. SSL hat einen schwachen
kurzlebigen Diffie-Hellman-Schlüssel in der Handshake-Nachricht "Server-Schlüsselaustausch"
empfangen. (Fehlercode: ssl_error_weak_server_ephemeral_dh_key)

Das bedeutet, das die anzuzeigende Seite gegen die Logjam-Attacke auf SSL verwundbar ist. Im Prinzip soll der DH-Schlüsseltausch PFS liefern, in einigen Implementierungen ist das Protokoll allerdings angreifbar. Die notwendige Sicherheit auf dem initialen Schlüsselaustausch liefern nur Schlüssellängen von 512bits und mehr, die anzuzeigende Seite möchte aber weniger. Das betriff viele Fritz! Boxen („fritz.box“), Speedport-Router der Telekom („speedport.ip“) und ähnliche Geräte.

Blöderweise liefert viel Hardware und viele Infrastrukturkomponenten die jeweiligen Web-GUIs mit so einer SSL-Konfiguration aus. Dazu zählen EMC, Nimble, HP, IBM, NetAPP, Cisco und fast jeder andere. Da Firmware-Updates an solchen kritischen Punkten oft etwas länger brauchen, benötigen Admins hier eine Lösung (abgesehen von der Wwahl, Chrome oder Edge zu nutzen).

Lösung

firefox-sslv3-fehler-gesicherte-seitenFirefox hat SSLv3 zum Glück noch nicht verlernt, sondern nur dekativiert:

  1. „about:config“ in der Adresszeile öffnen (und Warnung wegklicken)
  2. Suche nach „security.ssl3.
  3. Die beiden Einträge „security.ssl3.dhe_rsa_aes“ zu 128 und 265bit mittels Doppelklick auf „false“ stellen.

Veeam B&R: „Post-job script terminated with exit code 3“

Problem

veeam-post-job-script-exit-3In den Backup-Reports und in der Statusübersicht sind verschiedene Veeam-Sicherungen mit Post-Job Batch-Scripts mit „Warning“ markiert, obwohl der Job korrekt gelaufen ist. Das schreint ebenso für das Script zu gelten, es sind keine Fehler feststellbar.

Lösung

Veeam B&R wertet den Rückgabecode („ERRORLEVEL„) des Scripts aus. Alle Statuscodes außer „0“ werden als Warning im Bericht aufgeführt. Am einfachsten ergänzt man sein Script um einen exit mit dem code 0:

...
echo Done with hypercomplicated batch script.
exit 0