- Nov 1, 2013
Yes, and there's good reason for each choice made. Look, VMware's stuff has to actually WORK. ESXi is not a "bad actor" for having made pragmatic choices about being paranoid with VM data. They've made the safest reasonable choices that can be generally implemented across a variety of hardware - specifically including NON-SCSI hardware. VMware sits in between a VM that might-or-might-not have virtual hardware that vaguely resembles SCSI or might implement something like IDE, and then data storage through a variety of technologies including FC, iSCSI, NFS, SAS, and others. It has to all WORK. This is the sucky real world. Nothing prohibits an admin who dislikes VMware's pragmatic and conservative choices from overriding them. But I think we can at least respect VMware for trying to make sure that the storage system does the right thing.
I'm pointing out that it is clearly not working as it ought to. ESXi's iSCSI implementation is not issuing the appropriate SCSI commands to the target storage layer and is thus not respecting the semantics and guarantees that filesystems rely on - namely the ability to issue synchronous writes and be assured when they have reached NV storage. And because of this failure downstream NAS/SAN systems are having to massively overprovision their systems by assuming every write is a worst case sync write (via ESXi's NFS interface), when in reality (workload depending) they are some tiny fraction of actual writes.