ESXi 5.5 "hakt"

[andi65]

Hallo Forum,
ich habe hier ein seltsames Problem und bin nicht so sicher ob es sich um ein Hard- oder Softwareproblem handelt:

Umgebung:
ESXi 5.5 aktueller Patchlevel, vSphere auch aktuell

Hosthardware:
1 x Supermicro-Server (wird angezeigt als SYS-2028R-C1RT) mit 2 x Intel E52630, 256GB RAM, RaidController LSI 9361-8i mit 8 x Intel SSD DC S3500 im Raid6

Ich setze das aktuelle Horizon View ein um eine VDI-Struktur mit Windows 8.1 64bit zu erzeugen. Domänenserverseitig kommt Windows 2012R2 zum Einsatz.

Nun zum Problem:
Immer wenn ich mehrere w8.1 VMs gleichzeitig einschalte, kommt es zu Aussetzern, die ich daran erkennen kann, dass im esxtop für einige Minuten keinerlei Disk-Zugriffe stattfinden. Während dieser Zeit steht der ESX natürlich fast still, so dass es zu Verbindungsabbrüchen kommt. Auch ein Ausrollvorgang des Pools läuft nie sauber durch.
Seltsamerweise habe ich das Problem nicht, wenn ich die VMs mit Windows Server 2012R2 gleichzeitig einschalte.
Ich hatte zuerst das RAM in Verdacht und habe das getestet - keine Probleme. Danach das RAID getestet - keine Probleme.
Danach habe ich ESX-seitig den SAS-Treiber aktualisiert - keine Änderung.

Ich weiß derzeit nicht in welcher Richtung ich "weiterermitteln" kann. Hat jemand von Euch eine Idee?

Vielen Dank
Andi

[rprengel]

Nun zum Problem:
Immer wenn ich mehrere w8.1 VMs gleichzeitig einschalte, kommt es zu Aussetzern, die ich daran erkennen kann, dass im esxtop für einige Minuten keinerlei Disk-Zugriffe stattfinden. Während dieser Zeit steht der ESX natürlich fast still, so dass es zu Verbindungsabbrüchen kommt. Auch ein Ausrollvorgang des Pools läuft nie sauber durch.

Hallo,

tritt das nur beim Start oder auf auch im laufenden Betrieb?

Gruss

[andi65]

Nur beim Start - nachdem der ESX seine "5 Minuten" fertiggehakt hat, läuft alles wieder

[rprengel]

Nur beim Start - nachdem der ESX seine "5 Minuten" fertiggehakt hat, läuft alles wieder

Das kenne ich bei Systemen mich "schwachen langsamen" Festplatten wenn beim Start reichlich Dienste wie Virenscanner und Java-Server mit starten.
Win8 startet doch auch reichlich Mist mit wenn es hoch fährt.

Gruss

[andi65]

Ja, das vermute ich hier aber nicht - hier ist ein SSD-Raid mit einem schnellen Controller dahinter.
Die Disk-Anzeige im esxtop ist auch für den Controller in der Zeit komplett auf "0".

[stahly]

Ist der Raidcontroller (und sie SSDs) für ein SSD-Raid geeignet?

Hast Du die 8.1er VMs mal auf eine Single SSD gelegt?

[andi65]

Der Controller ist explizit für SSDs freigegeben. Testen kann ich das mit anderem Storage nicht, da ich nur dieses Raid als alleiniges Storage habe.

Ausschließen würde ich das auch, da die w2k12-r2 VMs keinerlei Probleme beim Starten machen.

[Dayworker]

Du hast ein bekanntermaßen schreibleistungsverminderndes Raid6 im Einsatz und deine Win8-VM sind mit welcher vRAM-Grösse ausgestattet?
Falls du dort mehr als 2GB zugeteilt hast, wird bei jedem VM-Start erstmal eine vmem-Datei in genau der vRAM-Grösse auf das Raid6-Volume geschrieben. Erst mit Server-2k12 hat M$ seinem Server-Windows den möglichen Betrieb in einer virtuellen Maschine zugestanden und erst seitdem kann sich ein Windows auch auf die damit einhergehende v.HW-Plattform einstellen. Keine Ahnung ob das auf die Desktop-Windows' auch zutrifft. Windows 7 und erst recht die 8er Starten aber viele Dienste erst verzögert, das sollte sich von der Warte nicht groß bemerkbar machen.

Ich tippe daher darauf, daß die vRAM-Config deiner Win8.1-Gäste deutlich zu großzügig ist und dein Raid6 nicht mit dem Anlegen und Testen der vmem-Datei hinterherkommt. Das könnte natürlich auch daran liegen, daß du das optionale "CacheVault Flash Module (LSICVM02)" nicht mitgekauft hast und daher der Raid-Controller beim Schreiben nicht seine vollständige Leistung bringen kann.

[mbreidenbach]

Raid 6 ist beim sequentiellen Schreiben in der Tat mies (um den Faktor 6 gegenüber lesen).

Aber - Swapfile wird ja nur angelegt wenn VM Memory > VM Memory Reservierung.

Man könnte also mal einstellen daß die VMs ihren Speicher reserviert bekommen dann gibts keine VMware swap files.

[andi65]

Hallo - erst noch mal Danke für eure Antworten...

Ich habe jeder w8.1 VM 4GB zugeordnet. Die gleiche Konfiguration habe ich aber auch auf einem anderem (ältere Hardware) System, bei dem es keine Probleme dieser Art gibt. Das gesamte RAM aller VMs kann auch im Server gehalten werden. Es wird nicht "geswapt".

Bitte noch mal zurück zum esxtop:
Wenn ich dort "d" für "Disk" drücke und dort minutenlang keinerlei Aktion auf dem vmhba3 (das ist der LSI-Raid-Controller) stattfindet tippe ich nicht in Richtung vRAM, Swap-Probleme oder langsame Schreibzugriffe.
Selbst wenn das System "in Ruhe" ist, werden in dieser Darstellung eigentlich immer ein paar "CMDS/s" angezeigt. In meinem Fall ist das tatsächlich länger komplett auf "0". Daher hatte ich auch schon den Verdacht in Richtung Hardware, konnte es aber nicht mit entsprechenden Tests bestätigen.

[~thc]

Das würde bedeuten, dass der ESXi aus internen Gründen nicht in der Lage oder willens ist, die ausstehenden Disk-I/Os auszuführen. Ich würde erst mal alle Logs des ESXi durchforsten - da müsste doch ein Hinweis zu finden sein.

[kastlr]

Hallo Andi,

verbinde dich doch mal per ssh mit deinem ESXi Server und führe dort ein tail -f /var/log/vmkernel.log aus.
Überprüfe zuerst einmal, ob dort interessante Meldungen mit dem Vermerk Warning oder Error erscheinen.

Öffne noch eine weitere Session und führe dort esxtop aus, um den Anzeigeintervall auf 2 Sekunden zu reduzieren gibst du bitte s 2 <Enter> ein
Die esxtop Session brauchst du eigentlich nur zur Bestätigung, ob dein System nicht völlig eingefroren ist.
Dazu kannst du ja zwischen den verschiedenen Ansichten wechseln und überprüfen, ob die Anzeige alle 2 Sekunden aktualisiert wird.

Nach einer Weile startest du dann mehrere VM's gleichzeitig und checkst die Logs erneut.
Sofern dein System nicht vollständig eingefroren ist sollten sich nun in der ersten ssh Session eigentlich Hinweise zu deinem Problem finden lassen.

Viel Erfolg,
Ralf

[Dayworker]

Ich habe jeder w8.1 VM 4GB zugeordnet. Die gleiche Konfiguration habe ich aber auch auf einem anderem (ältere Hardware) System, bei dem es keine Probleme dieser Art gibt.

Wie ist das ältere System HW-technisch ausgestattet?
Kommt dort auch dasselbe Raid6 samt Controller zum Einsatz?
Ist das optionale "CacheVault Flash Module (LSICVM02)" für den LSI-Controller installiert?
Wie sieht die VM-Config hinsichtlich vCPUs aus?

[andi65]

Das ist echt frustrierend...

Gestern war ich vor Ort und musste 2 x das System resetten da nix mehr ging. Alles was der ESX im RAM hatte (wie esxtop) funktionierte aber noch.

Ich wollte bei VMware ein Ticket aufmachen. Ich tippe im Moment auf den ESX, da es reproduzierbar nur bei w81 VMs passiert.
Da der Kunde aber noch in der Evaluierungsphase ist und daher (noch) keine Lizenz hat machen die nix - nicht mal ein "Einzel-Kaufticket" kann man bekommen. Tja...

Nochmal zu Euren Anmerkungen:
@kastlr:
Die vmkernel.log hatte ich auch schon am Wickel - da gar keine Zugriffe auf das Storage stattfinden wird da leider auch nichts eingetragen. Auch wenn die Zugriffe auf das Storage wiederkommen sind kann ich hier nichts entdecken.

@Dayworker:
Das ältere System ist hardwareseitig mit einem älteren LSI-Controller aber auch mit 8 x SSD im RAID6 aufgebaut. VMwareseitig kommen die gleichen Betriebssysteme (w2k12r2 und w81 64bit) zum Einsatz.
Den W81-VMs habe ich 2 vCPU und 4GB vRAM zugeordnet.
Das CacheVault Kit für den LSI 9361-8i ist (laut meiner Rechnung für die Hardware) installiert.

Gruß Andi

[Supi]

Hallo Andi,

ich klinke mich mal ein.

Dein Server hat 2x E5-2630, also 2x6 (12mit HT) CPUs.
Wieviele VM's schaltest du denn parallel ein? Brauchen die wirklich 2vcpu?

Nicht das du hier 10 VM's parallel startest und der Server ist leicht überfordert?
Dazu würden ja noch die 10x4GB "Auslagerung" des ESXI für die VM's kommen.

Welchen Treiber hast du denn für den Controller eingebunden?
Gibt ja doch einige:
http://www.vmware.com/resources/compati ... ctid=35237

Ob der Cache dabei ist müsste der ESXI doch auch unter HW Infos anzeigen, so du den SMIS Provider installiert hast.

Ist denn auch das FW Update aus dem April drauf?
http://www.lsi.com/products/raid-contro ... x#tab/tab4

SCGCQ00584299 - (Closed) - R5/R6 SSD 4K Random Write IOps lower than expected (at a QD fo 256)

Kannst du da nicht ggf mal ein kleines NAS hinstellen und per NFS einbinden und von dort 2-3 VM's starten lassen? Mir erscheint das sehr seltsam.

Selbst bei mir im "HomeLab" mit ESXi als "VM" in der Workstation (WS 11 unter Win764), in der ich dann wiederum virtualisiert ein paar VM's teste, habe ich solche probleme bei parallel start der VM's nicht. Und das bei VM's auf einer SATA HDD. Es dauert dann sicher ein gutes Stück, aber Aufhänger habe ich da nicht.

[UrsDerBär]

Wie sieht es mit dem Windows-Swap-File aus? Löschst Du das jeweils beim herunterfahren? Dann wird das beim Start auch neu erstellt. Bei 4GB über mehrere VM's kann das ganz schön viele IO's verursachen.

Die 3500er sind leider längst nicht so gut wie die 3700er oder die leider ausgelaufenen 520er. Vor allem auch punkto Latenz-Streuung. Im RAID-Betrieb kann das ganz schön nervig sein. Irgend eine Disc ist mit der Latenz sicher grad im katastrophalen Bereich und zieht die Performance des ganzen Disk-Sets runter. Je komplexer das RAID-Level, desto schlimmer wirds da viele Zugriffe stattfinden.
Das geht dann unter Umständen bis zur Unbrauchbarkeit unter Last. Würde daher ausschliesslich RAID 10 nehmen, da ist der Effekt zumindest teilweise minimiert.
Allerdings sollte der Effekt nicht so extrem sein. Wäre ja mieser als mit Magnetplatten.

Ansonsten sehe ich das wie supi (grad gesehen und meine Antwort gar ned abgeschickt gehabt heut morgen). CPU evtl. überbucht und daher nen Prob. Oder die Summe davon.

[andi65]

@Supi:
Der Server hat 2 x 8 CPU mit HT
Mit 2 vCPU laufen die VMs gefühlt deutlich besser - es gibt in der Installation auch recht hungrige Software wie z.B. Datev
Um das Problem zu "erzwingen" reicht es 3 w81 VMs gleichzeitig zu starten (wie gesagt - bei den w2k12r2-Servern ist das überhaupt kein Problem und die haben mehr RAM zugeordnet). Wie auch schon geschrieben funktioniert die VM-Konfiguration mit den selben Betriebssystemen auf einer älteren Hardware problemlos, selbst wenn tatsächlich 10VMs gleichzeitig gestartet werden. Das dauert dann natürlich, aber wenn sich der Boot-Storm gelegt hat ist wieder alles ok.

Controller-Treiber: Ich habe da die aktuelle Version von der LSI-Seite für ESX5.5 geladen und installiert
Controller-Firmware: Da gibt es eine neuere als die, die ich gerade nutze. Das werde ich heute abend mal aktualisieren.
Cache: SMIS-Provider sind installiert. Ich habe vorhin (musste mal wieder resetten) im BIOS des Controllers mal nachgesehen - ist aktiv.

Das mit dem NAS ist eine gute Idee - werde ich mal testen.


@UrsDerBär:
Ja, ich lösche die Swap-Partition. Aber selbst wenn viele IOs stattfinden darf es (eigentlich) nicht stehenbleiben.

Der Hinweis mit den Platten: Müsste nicht wenn eine der SSDs "spinnt" das System unabhängig vom Gastbetriebssystem zicken? Ich schau nachher mal im Controller-Bios nach ob man einen nondestruktiven Plattencheck durchführen kann.

Vielen Dank an euch.

Gruß Andi

[UrsDerBär]

Nee, die Platte zickt in dem Sinne ja nicht. Problematisch ist eben, dass die Latenz der eher günstigen SSD's sehr breit streut. Also manche IO's hauen sie sofort raus, für andere brauchen sie im extremfall sehr viel länger als ne Magnetplatte.

Wenn nun eine Platte im Einsatz ist, spielt das ned so die Rolle, je mehr aber zusammen in nem RAID-Set sind, desto extremer wird dieser Effekt. Bei RAID 6 wird so extensiv über alle Platten geschrieben und gelesen, dass das die Performance schon ziemlich schmerzlich belasten kann weil vielleicht bei fast jedem IO eine Platte an ihrer äusseren Latenz-Grenze läuft. Dass das aber nun tatsächlich soviel ausmacht, dass quasi nix mehr reagiert, finde ich schon auch seltsam. Eine Performance die schlechter ist als Magnet in nem RAID10 habe ich aber auch schon gesehen.


Wenn Du den Host resetten musst, dann dürfte das aber schon an was anderem liegen. RAM ist ECC Registered verbaut? Stromversorgung stabil? Temperatur der CPU's nicht extrem hoch?

[Supi]

@Supi:
Der Server hat 2 x 8 CPU mit HT
Gruß Andi

Ok, hatte nur nach 2630 geschaut.... und erst der V3 hat dann auch 8 CPU's.
http://ark.intel.com/de/products/83356/ ... e-2_40-GHz

Aber wenn das wirklich mit 3 VM's schon auftritt, dann teste wirklich mal mit einem NAS. Oder halt mal ohne " Clear Virtual Memory Pagefile at Shutdown".

[andi65]

Ich habe nun die aktuelle FW auf dem Controller geflasht und danach noch mal die aktuellen Treiber (diesmal von der VMware-Seite) eingespielt. Hier mal die entsprechenden Abfragen (der vmhba3 ist übrigens der relevante Controller):

# esxcfg-scsidevs -a
vmhba38 ahci link-n/a sata.vmhba38 (0:0:31.2) Intel Corporation Wellsburg AHCI Controller
vmhba39 ahci link-n/a sata.vmhba39 (0:0:31.2) Intel Corporation Wellsburg AHCI Controller
vmhba0 ahci link-n/a sata.vmhba0 (0:0:17.4) Intel Corporation Wellsburg AHCI Controller
vmhba1 ahci link-n/a sata.vmhba1 (0:0:31.2) Intel Corporation Wellsburg AHCI Controller
vmhba2 lsi_mr3 link-n/a sas.5003048016b70100 (0:1:0.0) Avago (LSI / Symbios Logic) MegaRAID SAS Invader Controller
vmhba3 lsi_mr3 link-n/a sas.500605b00a09d260 (0:133:0.0) Avago (LSI / Symbios Logic) MegaRAID SAS Invader Controller
vmhba32 ahci link-n/a sata.vmhba32 (0:0:17.4) Intel Corporation Wellsburg AHCI Controller
vmhba33 ahci link-n/a sata.vmhba33 (0:0:17.4) Intel Corporation Wellsburg AHCI Controller
vmhba34 ahci link-n/a sata.vmhba34 (0:0:17.4) Intel Corporation Wellsburg AHCI Controller
vmhba35 ahci link-n/a sata.vmhba35 (0:0:31.2) Intel Corporation Wellsburg AHCI Controller
vmhba36 ahci link-n/a sata.vmhba36 (0:0:31.2) Intel Corporation Wellsburg AHCI Controller
vmhba37 ahci link-n/a sata.vmhba37 (0:0:31.2) Intel Corporation Wellsburg AHCI Controller

# esxcli software vib list | grep lsi
lsi-mr3 6.607.08.00-1OEM.550.0.0.1391871 Avago VMwareCertified 2015-06-18
lsiprovider 500.04.V0.55-0006 LSI VMwareAccepted 2015-06-14
lsi-msgpt3 00.255.03.03-1vmw.550.1.15.1623387 VMware VMwareCertified 2015-03-28


Nun bekomme ich auch mal vernünftige Anzeigen in der vmkernel.log. Ich erhalte (nur beim Einschalten einer w81-VM, nicht bei w2k12r2) folgende Meldungen:

2015-06-19T06:54:44.933Z cpu28:289466)WARNING: NetDVS: 547: portAlias is NULL
2015-06-19T06:54:45.596Z cpu16:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:45.693Z cpu30:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:46.691Z cpu0:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:47.690Z cpu18:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:48.619Z cpu24:289457)WARNING: VSCSI: 3565: handle 8341(vscsi0:0):WaitForCIF: Issuing reset; number of CIF:1
2015-06-19T06:54:48.619Z cpu24:289457)WARNING: VSCSI: 2487: handle 8341(vscsi0:0):Ignoring double reset
2015-06-19T06:54:48.696Z cpu3:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:49.690Z cpu16:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:50.691Z cpu24:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:51.764Z cpu21:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:52.692Z cpu0:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:53.692Z cpu0:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:54.693Z cpu16:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:57.669Z cpu1:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:57.695Z cpu0:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:58.692Z cpu27:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:54:59.692Z cpu17:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:55:00.692Z cpu20:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:55:00.809Z cpu20:289457)WARNING: VSCSI: 3565: handle 8341(vscsi0:0):WaitForCIF: Issuing reset; number of CIF:1
2015-06-19T06:55:00.809Z cpu20:289457)WARNING: VSCSI: 2487: handle 8341(vscsi0:0):Ignoring double reset
2015-06-19T06:55:01.692Z cpu10:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:55:02.692Z cpu19:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:55:03.698Z cpu16:33667)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:55:04.691Z cpu0:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...
2015-06-19T06:55:05.700Z cpu2:33666)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.600605b00a09d2601ca8400f0f0d43c0" state in doubt; requested fast path state update...


Meinen Recherchen zufolge könnte es sich hierbei sowohl um Hard- als auch um einen Softwarefehler handeln. Irritierend ist für mich, dass das nur bei w81-VMs auftritt.

Seit dem Update habe ich wenigstens keinen Totalausfall mehr zu beklagen. Aber ok ist das sicherlich nicht.
Danke und Gruß Andi

[UrsDerBär]

Schon sehr seltsam das ganze. Ich hatte mit 8.1 Probleme mit vEFI, aber kein Plan mehr was die Fehlermeldungen genau waren. Gab aber auch Freezes. Aber nicht auf dem ganzen Host. Aber nachschauen kannst ja trotzdem ob Du bei 2012R2 bios und bei 8.1 efi nimmst. Aber Controllerfehler sollte es deswegen eigentlich nicht geben.

[Dayworker]

Wenn du jetzt noch sagen würdest, was VMware mit "naa.600605b00a09d2601ca8400f0f0d43c0" bezeichnet, würde uns das natürlich etwas weiterbringen...
Aber ausgehend von http://blogs.vmware.com/kb/2012/04/storage-performance-and-timeout-issues.html bedeutet eine Meldung mit nmp_DeviceRequestFastDeviceProbe:237: NMP device "LUN-Nummer" state in doubt; requested fast path state update... im Endeffekt fast immer, daß der Controller überlastet ist. Das führt uns wieder zu deinem Raid-Level und dem Controller. Stehen sowohl Raid-Level als auch die SSDs auf der LSI-HCL und ist dein Raid-Level auch von Intels Seite so freigegeben?


Das es mit Win2k12(-R2) da zu keinen vmkernel-Einträgen kommt, überrascht mich eigentlich nicht wirklich. Erst diese Win-Version kann sich aktiv auf die Ausfährung in einer virtuellen Maschine einrichten.



[add]
VMware hat dazu auch den KB-Eintrag mit Information about the error: state in doubt; requested fast path state update (1022026) verfaßt.
Einige Ursachen sind aufgeführt:

• Array backup operations (LUN backup, replication, etc)
• General overload on the array
• Read/Write Cache on the array (misconfiguration, lack of cache, etc)
• Incorrect tiered storage used (SATA over SCSI)
• Fabric issues (Bad ISL, outdated firmware, bad fabric cable/GBIC)