Before I went to all that work to defrag the drive + DB's just to satisfy a generic warning message, I would do a few things:
What would you expect to get out of it? Exchange Server fragmentation is largely irrelevant to your users if they are all using Outlook cached mode. If Exchange is given enough RAM, it's storing chunks of each mailbox in RAM so your disks become less important. Modern Exchange is actually designed to run on slower disks then old Exchange (2000/2003).
Defragmenting inside a VM is not what you think it is. You've got multiple levels of abstraction between your physical disks and the exchange DB's. You've got a RAID set serving up a LUN off of a shared set of iSCSI disks, how do you know if that LUN is contiguous on the actual disks? I doubt it is, especially if it's thin provisioned. Then you've got a .vmdk file you created in VMWare, which is likely fragmented itself. Did you thin provision it, or ever change the .vmdk size after initial creation? If you went through all these different levels starting with iSCSI, then to vmdk, then to guest OS, then to Exchange... what would it result in? Maybe faster OWA, if that...
Bottom line is I've never seen production systems that are virtual get defragmented and actually result in an improvement in the user experience. I'm not saying it's impossible to do... I'm just saying it's unlikely.
Tips on VMWare VM's and defragging:
One interesting quote from that link:
"I should point out that I have read that, internally at VMware, we
have not observed any noticeable improvement in performance after a
defragmentation of Guest OSes residing on SAN or NAS based