Vsphere is now telling us that it wants to be on the FJP7 firmware. We are currently on 8DV10171 and the intel tool tells us it would upgrade it to 8DV101H0?!? What firmware are people on here having the most success with ATM? We are on the 126.96.36.199-4vmw driver.
We're currently on 8DV10171 with 188.8.131.52-4vmw on 6.5U1 I don't know what the FJP7 comes from, looks like it is a Fujitsu firmware, but we are using Intel branded P3700s. Everything is working fine for us and everything is on the HCL. It seems that the health check is never going to work with these drives.
One thing to note, at one point we started seeing slow cloning performance after an update while we were on 6.0U3. Just found this: https://kb.vmware.com/kb/2149876. Doesn't seem to affect normal operations, but very disappointing as we have invested heavily in the P3700s as cache drives in all of our hybrid and all-flash clusters.
We are testing some P3700s for vFlash Read Cache and the performance is shit there as well. I asked support if the KB you mentioned, could also cause issues with vFlash Read Cache and I was told
"we do know that the NVMe device in question (I.E. your HP "MO1600KEFHQ" also known as "1.6TB NVMe PCIe Write Intensive SFF 2.5-in SC2 764892-B21" which is basically a re-branded Intel P3xxx ) is affected by serious performance issues when dealing with continuous writes in the same blocks or block range. Although this was noticed specifically with vSAN environments, it is reasonable to state that the bad performance "scenario" (it's actually not a bug, I believe, of the device itself but rather a design flaw) of the P3xxx would be exploited with any intense use of the device itself, like for example, vFlash cache in conjunction with write intensive applications like DB servers."
We were directed by GSS to disable the firmware version healthcheck. We are running retail Intel P3700's and the DID, VID, SDID and SVID values are identical for both Intel and Fujitsu and atleast one other brand.
We were also instructed to disable log compaction in regards to KB2149876. If log compaction isn't disabled you'll notice very high latency values during certain scenarios (I uncovered this while watching esxtop after completion of a proactive stress test. During the deletion process the latency would spike for 15-20 minutes)
After these two changes our vSAN environments have been performing flawlessly on retail Intel P3700's and S3520's for capacity.
I have a ton of Intel P3700s in production, have only seen the high latency values on the P3700 infrequently, but unfortunately at some critical times (during resync from dying hardware or during a host failure). How do you disable log compaction in VSAN? And if disabled, can it be safely re-enabled at a later time?