[solved]VCenter 7

[hutzi]

Hi liebes VMware Forum, liebe Experten,

ich grüße euch. Ich komme mit einem Problem zu euch, dass mir Kopfzerbrechen bereitet, vielleicht ist jemand von euch schonmal darüber gestolpert.

Folgende Situation. Upgrade von vCenter 6.7 auf 7.0.3.01100 durchgeführt. Eigentlich auch alles tutti.
Nun gab es allerdings seit dem Update bereits zwei VM's (einmal linux, einmal windows) die das gleiche Fehlerbild aufgewiesen haben, die Linux Kiste ist zum 4ten mal davon betroffen.

Fehlerbeschreibung
Die VM reagiert nicht mehr. Komplett tot. Über die vCenter Konsole sieht man noch den command prompt aber tippen ist nicht mehr möglich. VM kann nicht heruntergefahren oder hart ausgeschalten werden; faktisch ist gar kein management der VM mehr möglich.
Fehler tritt scheinbar zufällig auf. Mal 4 Wochen nicht, dann zwei mal innerhalb von 3 Tagen.

Bisherige Fehlerbehebungsversuche
Ich bin also über SSH auf dem ESX Host und habe mir über esxcli die VM rausgesucht:

Code: Alles auswählen

[root@servername:~] esxcli vm process list | grep 9665414 -C3
VMName
   World ID: 9665419
   Process ID: 0
   VMX Cartel ID: 9665414
   UUID: 42 37 3c d3 cc c2 59 20-ee 99 73 4d c8 f9 f3 11
   Display Name: VMName
   Config File: /vmfs/volumes/5e35fd2e-ca4e3096-0e2c-98f2b32ab622/VMName/VMName.vmx


Da nichts mehr ging wollte ich das Teil abschießen:

Code: Alles auswählen

esxcli vm process kill -t=hard -w=9665419

Nach dem abfeuern des Befehls kommt kein Fehler. Alles ok - allerdings ist das Ding im selben Zustand wie zuvor auch. Also nochmal die process liste geholt, teil immer noch da. Nochmal versucht zu killen, keine Chance:

Code: Alles auswählen

Unable to kill Virtual Machine. Error was : Unable to kill virtual machine.  Error returned was No such process

Ich habe daraufhin das vCenter neu gestartet, und beiden für das Cluster zuständige ESX-Server haben von mir einen "services.sh restart" bekommen - das Teil ist immer noch da.

Offene Fragen
1. Was kann ich noch versuchen um diesen Zustand zu beheben? Aktuell stelle ich die VM aus dem Backup wieder her und vergebe eine neue MAC-Adresse damit die alte VM nicht mehr stört. Das Teil ist knapp 800gb groß und der Prozess dauert daher einige Zeit und ist natürlich nicht Sinn der Sache
2. Irgendwelche Ideen, wodurch das Verhalten auftritt und wie ich es zukünftig verhindern kann?

Vielen Dank und viele Grüße

[irix]

Moin,

aus der Ferne kann ich da nichts sagen aber ich wuerde mich da nicht auf das vCenter konzentieren sondern eher den ESXi... weil der fuehrt die VMs aus.

1. Fuer vCenter gibts die 01400
2. Welche Version hat denn der ESXi?
2. vmware.log bzw. hostd.log/vmkernel

Die Frage wie schnell es immer auftritt... wenn du dein vCenter ausschalten kannst dann macht das doch einfach mal. Allerdings geht bei allen das Backup ueber das vCenter.

Gruss
Joerg

[hutzi]

Moinsen Joerg,

Danke für Deine Antwort. Du hast natürlich Recht - viel wahrscheinlicher, dass es am ESX liegt, jetzt wo Du es sagst.

ESX Version:
Clientversion: 2.1.1
Client-Build-Nummer: 20188605
ESXi-Version: 7.0.3
ESXi-Build-Nummer: 20842708

Hostd log von dem Tag sieht schonmal vielversprechend aus. Angeblich wurde für einige Sekunden die Verbindung zu beiden LUNs verloren.
Das könnte doch schon die Ursache sein, nehme ich an. Wenn der Server weshalb auch immer darauf deutlich zickiger reagiert als andere Systeme.

So ein Ansatz hat mir gefehlt, vielen Dank fürs auf die Sprünge helfen. Ich melde mich nochmal wenn ich weitere Neuigkeiten habe.

[irix]

Wenn es um LUNs geht ist das vmkernel.log das richtige. Ein Linux OS reagiert bei uns auf Festplattenausfaelle bedeutend "zickiger" als ein Windows.

Was ESXi Version angeht ist bei 7.0.3 was deutlicher neueres verfuegbar.

Gruss
Joerg

[hutzi]

Ganz blöde Frage - gibts irgendwo eine Art Übersicht welches Log bei welchen Problemen das richtige ist?
Ich hatte grundsätzlich durch die logs geschaut, aber das hostd.log wohl nicht auf dem Schirm gehabt.

Ja ich weiß werde die ESX Server demnächst auf Stand bringen.

[hutzi]

Vielen Dank für die Unterstützung, Irix.
Ich wollte nur nochmal feedback geben, dass das Problem bisher nicht wieder aufgetaucht ist.

Die Logs haben mich zum Storage geführt, wo aber alles OK war. Allerdings hatte einer der Switche zwischen den Servern und dem Storage eine 100% CPU last und scheinbar teilweise die Verbindung unterbrochen. Der Switch wurde neugestartet und läuft seither wieder einwandfrei.
Interessant ist eigentlich nur dass VMware diesen iSCSI path präferiert hat, obwohl es noch einen weiteren Path zu der selben LUN über einen normal funktionierenden Switch gab.

Wie auch immer. Vielen Dank für die Unterstützung.

[irix]

Gibt ja nun unterschiedliche Pfad Policies im ESi und da die Frage welche denn konfiguriert ist. Des weiteren ist es ja fuer ein System nicht ganz einfach mit einem "fluktuierendem" Zustand umzugehen. Wenn ein Pfad wegbricht und nicht wieder kommt ist das definitiv einfacher als so "geht ein bisschen".

Danke fuer die Rueckmeldung.

Gruss
Joerg