That’s because fragmentation can occur both inside the host operating system as well as within the guest. Think for a minute about the problem. From the perspective of the host, each of the files on that host’s volumes can (and will) grow fragmented as they’re used. This means that VHD and VMDK files will both become fragmented over time.
I highlight “will” here, because fragmentation is a natural by-product of file system operations. Without some solution to reverse that fragmentation, you’ll see file system performance slow down over time.
As I’m aware (and please correct me if I’m wrong) there is no native solution in ESX that defragments its volumes. For Hyper-V, Windows has a native defragger. But that native tool is disabled by default on the Windows Server OS. You need to specifically turn it on.
The real impact happens when you combine this host-perspective fragmentation with the additional fragmentation that occurs inside the VM. The running of that VM also produces fragmentation (as the same “natural by-product). Thus, defragmentation must occur there as well. The same turned-off-by-default situation exists with Windows Server in the VM as well. Desktop OSs like Windows 7 et al have their native defragger turned on.
There are a number of solutions out on the market that integrate well with server environments, and a few that are now also considering the special needs of virtual environments. A good solution will be one that can accomplish its defragmentation tasks without impacting total system performance. This requirement grows particularly important in virtual environments, where you could logically have defragmentation tools installed all over the place (in VMs and on the host).
One solution that crossed my desk earlier this week is DisKeeper’s V-locity 2.0, which now integrates into both ESX and Hyper-V environments at both the host and guest level. While I haven’t yet done an analysis of its efficacy, I appreciate this solution’s holistic approach to what is really a multi-fanged problem.
