A recurring question is whether virtual machine guests should be defragmented to improve performance. The quick and dirty answer is that vSphere guests probably shouldn't and that Hyper-V guests might, under certain situations.

File level defragmentation comes from a heritage of non-virtualized systems on single disks or mirrored disks (RAID 1). In such situations, fragmentation of a file can result in slower reads and writes due to the underlying disk needing to perform a seek in the middle of the operation. Defragmentation of a file can reduce the number of disk seeks to perform disk operations. Sequential I/O operations are traditionally faster than random I/O operations.

If an organization is following best practices, guests should be stored on a disk array in RAID 10 with enough spindle to meet the IOPS requirements of the various guests. In such a storage situation, what looks like sequential I/O to the guest is aggregated across all drives in the array, since the storage is striped across drive pairs. In addition, when multiple guests are on the same array, the aggregated disk I/O will approach what looks like random I/O, regardless of how contiguous the files inside the virtual disks look to the guest. This factor will be even more exaggerated with thin provisioned LUNs on the array and thin provisioned virtual disks both working to randomize assignments from the underlying storage.

VMware vSphere Blog entry: Should I defrag my Guest OS?
http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html
Things are a little clearer in VMware vSphere environments because of Changed Block Tracking (CBT), a vSphere feature which identifies disk sectors which have been altered since the last “change ID.” VMware KB on CBT: Changed Block Tracking (CBT) on virtual machines
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020128
Defragmentation changes lots of disk sectors, resulting in more immediate disk I/O (which almost certainly wasn't taken into consideration during workload profiling), and bloats the list of changed blocks, resulting in lots more data being passed during anything relying on CBT, most likely differential backups and workload replication replication. Also of note are the ideas that a thin-provisioned guest will have size bloat due to the new disk blocks being used. Another interesting scenario mentioned is that of multi-tiered storage back-ends which tier by block, not file. Thus, different portions of a file might be stored on completely different arrays anyway. Not to mention that lots of I/O to what might be cold files will present garbage input to tiering algorithms.
It is fairly clear that the combination of CBT with array striping and potential workload aggregation, that vSphere guests should not be defragmented.

Microsoft Technet Article: Hyper-V: Defragmentation
http://social.technet.microsoft.com/wiki/contents/articles/738.hyper-v-defragmentation.aspx
An interesting laying out of the issues of fragmentation, pointing out that guest fragmentation is a third level of fragmentation after array-level “fragmentation” due to striping and LUN file system fragmentation. The author points out that there might be value in defragmenting after a P2V (Physical to Virtual) conversion of a heavily fragmented file system which is done at the block level instead of file level; A file level conversion would have the effect of defragmenting during the copying process. It looks like a P2V process should involved defragmentation before conversion to ensure a clean guest.

Using VHDMOUNT for off-line defragmentation of VHD internals: How To Compact Virtual Hard Drives
http://icodehead.blogspot.com/2009/01/how-to-compact-virtual-hard-drives.html
For those using VHD in a Windows environment, one option is to do an off-line defragmentation by mounting a VHD file (with the guest off, of course), and defragging it using the OS tools. If using a workstation for the job, the VHDMount tool is present in Microsoft Virtual Server.
Microsoft Virtual Server
http://www.microsoft.com/windowsserversystem/virtualserver/
It's also present in Windows Server 2008 R2 Disk Management console snap-in. And in Windows 7.
Common Scenarios for Attaching VHDs
http://technet.microsoft.com/en-us/library/dd799282(v=ws.10).aspx#BKMK_commonScenarios

Using disk-management tools to create and attach a VHD for offline image management. You can attach a VHD by using the Attach vdisk command which activates the VHD so that it appears on the host as a disk drive rather than as a .vhd file.