When I reverted a VM to snapshot just now, I got this message:
Seeing as the VMDK sits on an Intel X25-M SSD, I'm not sure what to make of it - defragmenting as the message suggests would probably hurt more than it would help.
This means only that the virtual disk needs defragmentation and hurts a ssd not more than any other write access.
That doesn't really answer the question though: why would a virtual disk sitting on an SSD need defragmentation in the first place?
Heck, given how all SSDs purposely scramble incoming writes across as many NAND devices as possible at the controller level for performance reasons, I'm not even sure if any meaningful form of defragmentation is even possible.
Dayworker explanaition is correct. Why Workstation would care if you have VM installed on SSD or SATA drive? It is transparent to it.
Please read more about defragmentation Defragmenting and shrinking VMware Workstation virtual machine disks (2019649)
Perhaps it is related to TRIM. Remember that the host's OS does not know what parts of the virtual disk are unused so it can't pass TRIM for them to the SSD but if you compact the virtual disk TRIM happens to the host's SSD.
It would be nice if Workstation allowed us to use its own file system on raw partitions to let it could pass the virtual TRIM from the guest to the host OS. (VMFS on raw partition maybe) Is it that different from VAAI sending UNMAP to a SAN on ESXi? We need that enterprise technology put into Workstation.
There are three types of fragmentation relevant to VMs, which I've outlined in an answer on superuser.
The message being shown here is about the second type (fragmentation of the .vmdk file itself). This means that a sparse .vmdk file is grown out of order, and if the guest later tries to read contiguous chunks from that .vmdk, Workstation can need to read from many different parts of the file. Consequently, Workstation could be issuing many, many more I/O requests than it would if the .vmdk were defragmented.
If you don't use a sparse .vmdk (and don't use snapshots), then this won't be a problem.
Your post has prompted VMware to investigate this under ticket #1808900 and we found that high fragmentation of virtual disks residing on physical SSDs causes "no notable changes in performance". This message will no longer appear in the future. Thank you for your input.
So why do you suppose, in December of 2019, my VMware Workstation 14.1.8 system, running on an all-SSD platform (on which my VM's .vmdk's are also housed) prompts me with the exact same "A fragmented virtual disk is affecting the virtual machine's performance. Defragment the following virtual disk..." instruction that I should use VMware's VM settings to defragment my vm's virtual disks?
It's very hard to resist a clear advisory from your platform-of-choice (VMware) to perform maintenance that it claims will improve performance.
I would not defragment your SSD. Your SSD manufacturer should take precedence over VMware on this question. As you know, the SSD does not suffer the slowdown of a sequential read on a hard drive. VMware needs to make explicit exactly how to handle this now more common than ever reality on SSDs as they are now the predominant mass storage devices on computers these days.
Technically, VMware should allow defragging, but in a TRIM fashion and should explicitly say so in their application once the app has detected an SSD. User should not have to make these decisions which could be incorrect and cause some serious problems.
Companies have actually sued software utility application companies when they do not either inhibit or state what to do with their application when it comes to computer systems and hardware. This is no different than mislabeling or no labeling any product which due to the lack of labeling causes user damage!!
I updated ticket #1808900, mentioned above, with this behavior. I see one instance of that message is still in the current code. The ticket was previously closed after addressing the issue elsewhere.