This was originally prompted by the IObit defrag app recently on GOTD, but as the app was reporting no more activations by noon, figured that there was no rush. It's a terrible app BTW, & IMHO of course, but AFAIK doesn't trash Windows at least.
That out of the way, I do a LOT of defragging on the VHDs [Virtual Hard Disks] that my VMs are installed on. I use dynamically expanding VHDs, which ideally are just big enough to hold whatever files are there, & no bigger. That way I can have a VHD with a capacity of 120GB, but that only takes up ~15GB on disk. Dynamically expanding VHDs take extra work however -- they grow for example after Windows Updates, & then have to be compacted [shrunken] back down to a smaller size. The 1st step to compacting a VHD is to pack all the data towards the front of the disk -- defragging -- which I generally do one or two times per month for each VM.
And I've noticed or found some peculiarities that may interest anyone that's defragging to pack the front of the disk, e.g. in preparation for shrinking that partition. Regular defragging doesn't necessarily pack everything to the front -- it puts the small chunks that make up each file in order & side by side, but it doesn't always move everything to the front of the disk. Windows itself can foil attempts to pack all data to the front of the disk by placing non-moveable files a good way into the drive storage -- at least at one time it was thought that that storage area was more reliable, & less prone to trouble.
Unlike win7, Windows 10's disk optimization often moves those immovable files towards the front of the disk, but it sometimes puts the NTFS file table's reserve storage area a good way into the disk storage, so the final result *might* not be the best possible. And win10's defrag does not pack the front of the drive as much as possible. For that I use MyDefrag set to "Consolidate free space", after I've run the optimization in win10.