VMware-Forum

Moin,

ich bin am verzweifeln mit meinem vSphere 6.5 Host - es werden einfach immer im Wechsel 2 VMs (es sind 2 Terminal Server 2012R2) sporadisch vom ESXi ausgeschaltet mit folgender ESX Fehlermeldung:
Eine auf einem ESXi-Host ausgeführte
Anwendung (/bin/vmx) ist abgestürzt (bereits 2-
mal). Eine Kerndatei wurde möglicherweise um
/vmfs/volumes/5899ea65-23b19500-ea00-1c98e-
c160e5c/TS2/vmx-zdump.001 erstellt.
Warnung
Fehlermeldung zu TS2: VMWare ESX nicht behebbarer Fehler:(vcpu-13) MXUserAlloSerialNumber: too many locks!

Die vmx.zdump Datei kann ich nicht öffnen und habe ich auch nicht durch online Recherche heraus gefunden, mit welchem Tool sich die Dump Datei lesen lässt.

Der Fehler tritt ca. alle 1-2 Monate einmal auf und es betrifft nur immer einen von beiden Terminal Server.


Die eingesetzte Version lautet: HPE Customized Image ESXi 6.5.0 version 650.10.1.0.47 released on July 2017 and based on ESXi 6.5.0 Vmkernel Release Build 5310538 - also das aktuellste
Es handelt sich um einen Host mit folgende technische Daten:

Modell: HP ProLiant DL380 Gen9
CPU: Logische Prozessoren 32
Prozessortyp Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
Sockets: 2
Kerne pro Socket: 8
Arbeitsspeicher 95,87 GB
SCSI Controller: integrierter HPE P440ar
HDDs im Server integriert mit 2x Backplaine: 14x 600GB 15K SAS im RAID6 Verbund konfiguriert
2x 200GB als Smart Cache im RAID 1 Verbund konfiguriert mit HPE Smart Cache Lizenz (das ganze macht sich performance technisch jedoch null bermerkbar auf den VMs, HPE hat dazu nur schwammige Aussagen getroffen obwohl dies bei denen hoch angepriesen wurde von den Testergebnissen was die iops betrifft.

installierte VMs: 12 Stück
davon 8xWin Server 2012R2
2xWin 7
2x CentOS 5

Der Fehler tritt allerdings wie gesagt nur bei den beiden Terminal Server auf - im Windows Log ist nichts zu sehen was damit zusammen hängen könnte.
Ich habe den beiden Terminal Server jeweils 16 vCPUs zugewiesen mit jeweils 4 virtuelle Sockets um kurzzeitige Spitzen abzufangen. Die beiden Sockets auf dem Host sind aber in der Gesamtauslastung im Durchschnitt immer nur bei 20-29%, beim Arbeitsspeicher zwischen 88 und 90% Gesamtauslastung.
Kann der Fehler daher kommen, das ich zu viele vSockets zugewiesen habe?
bei den restlichen VMs habe ich jeweils immer 2 vSockets zugewiesen.

Vielleicht kann mir jemand weiterhelfen, ich bin am verzweifeln.
Ich habe nur eine Essential Lizenz und kann daher den VMWare Support nicht befragen.

Beste Grüße aus dem schönen Hamburg, Mark

Das ist ein bekannter Fehler:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2149941

Entweder Update 1 installieren oder Workaround anwenden.

Hi, vielen Dank für die Antwort,

aber das HPE Custom Image ESXi 6.5U1 vom 27.07.2017 beinhaltet doch das U1 oder nicht?
Ich habe auf HPE 6.5U1 Anfang August aktualisiert mit einer Update Installation. Der Fehler ist nun aber innerhalb 1 Woche 2x passiert.
Also sollte ich den Workaround durchführen und den guest_rpc.rpci.usevsocket = "FALSE" Parameter wie beschrieben hinzu fügen?

Beste Grüße

ESXi 6.5 Update 1 hat die Buildnummer 5969303. Deine HP-Version basiert laut deinen Angaben auf dem vorherigen Build.

HPs U1 ist scheinbar unabhängig vom ESXi Update 1.

Alles klar, danke!

Ich werde den Workaround durchführen und dann sollte sich das hoffentlich gegessen haben.

Eine andere Frage nebenbei, was würdet ihr empfehlen bezüglich der Custom Images?
Mir wurde jetzt des öfteren empfohlen immer das originale VMWare Image zu verwenden aber womit ich dann hadere ist das ich nicht alle Sensoren im vSphere zur Verfügung habe?
Was ist da die optimalste Lösung, die HP Pakete manuell nachinstallieren?

Ohne jetzt fuer HPE Partei ergreifen zu wollen, aber: Man bekommt, was man herunterlaedt.

Auf der VMware-Seite findet sich hinter
VMware-ESXi-6.5.0-5310538-HPE-650.10.1.0.47-Jul2017.iso
wie der Name schon sagt ein Image fuer 6.5 OHNE U1

Es gibt aber auch
VMware-ESXi-6.5.0-Update1-5969303-HPE-650.U1.10.1.0.14-Jul2017.iso
und da ist (hoffentlich, zumindest laut Build-Level) das U1 schon mit drin.

Tatsaechlich kamen die beide im Juli...
(Edith: Stand jetzt. Ob in der Vergangenheit vielleicht mal das 6.5er als 6.5u1er auf der Download-Seite angeboten wurde, entzieht sich meiner Kenntnis.

Bzgl. der Verwendung von Custom Images ist meine persoenliche Empfehlung:
IMMER die Hersteller-Images verwenden, weil
- Da verantwortet der Hersteller der Hardware, dass die mitgelieferten Treiber auch mit der Hardware funktionieren
- Die Custom Images kommen zwar meist seltener und etwas spaeter, aber dafuer ist der entsprechende ESXi-Build dann auch schon etwas "abgehangen", und ganz krasse Fehler wurden (von Early Adopters) gefunden

Wer dagegen unbedingt immer der Maxime "Neuer ist immer besser, und ich bin nur mit dem Allerbesten zufrieden" folgt, installiert jeden Patch moeglichst noch VOR der Verfuegbarkeit...

Wovon man auf jeden Fall absehen sollte ist, urspruenglich mit einem Custom Image zu installieren, und ab da lediglich VMware's eigene Update-Seite zu konsultieren (entweder manuell, oder per Update-Manager), weil dadurch die zusaetzlich vom Hersteller eingebauten Komponenten irgendwann anfangen zu stinken, wenn sie nicht aktualisiert werden, um wieder zum verwendeten Base-Build zu passen.

Zeitweise hatte sich VMware's Support frueher mal "angestellt", wenn man nicht das Original von VMware selbst verwendete. Das ist aber bei den "offiziellen" Custom ISOs mittlerweile nicht mehr der Fall. Immer noch kann man aber gebeten werden, doch mal ein paar hersteller-spezifische Pakete zur Ursachenanalyse zu deinstallieren.

Stimmt!
Ich habe mich so sehr auf den Monat gestützt das es mir ehrlich gesagt nicht aufgefallen ist das im Juli 2 Custom Images von HPE veröffentlicht wurden.
Dann ist auch wieder alles gut!

Danke für das Feedback bezüglich der Verwendung von Custom Images!
I