ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
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.
Per SSH auf die Maschine und alle Dateien sowie Ordner (und enhaltene Dateien) aus /var/log/vmware/logbrowser/ löschen. Reboot, fertig.
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.
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:
- ESXi 6.0 Update 1 and later, available at VMware Downloads.
- ESXi 5.5 Update 3b and later, available at VMware Downloads.
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.
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
Das Erstellen eines oder mehrere Snapshots, zum Beispiel durch Backupsoftware (Veeam, R2Data, Tivoli …) erzeugt Fehler und Warnungen im Eventlog des Windows-Servers:
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.
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:
C:\ProgramData\VMware\VMware Tools\Tools.conf
[vmbackup] vss.disableAppQuiescing = true
Und schon laufen externe Snapshots ohne Quiescence auf diesem System. Hoffentlich wird das bald gefixt …
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“.
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.
~ # 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.
~ # kill -9 <PID>
~ # vim-cmd vmsvc/getallvms |grep MASCHINE
22 MASCHINE [vol1] CBHDC/CBHDC.vmx windows8Server64Guest vmx-08
36 MASCHINE4 [vol1] CBHDC1/CBHDC1.vmx winNetStandardGuest vmx-07
~ # 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.