Does virtual hard disk fragmentation reported by a guest machine matter?

If your VM is on local raid 5 storage, go ahead and defragment. But if it is on shared storage of any sophistication (SAN or NAS), talk to your storage guys first. There may be thin provisioning or deduplication going on at a layer VMware doesn't know about, and defragmenting can make the VM use a lot more space or even perform worse.

Also, if this is ESXi version 4, and the virtual disk is thin provisioned at the VMware layer (even on local storage), defragmenting will make the VMDK use more space as new blocks are written. This could also permanently slow things down by fragmenting the VMDK file on the VMFS layer as newly written blocks are allocated by VMFS out-of-order from the guest's perspective. A clone or convert operation would be needed to put things right again.

Yes. It also matters at the host.

Like physical disk drives, virtual disks can become fragmented. Performance is weakened by fragmentation on the physical disk holding the virtual machine's working directory or virtual disk files.

First defragment inside the virtual machine. Then power off the machine, and run a defragmentation utility on the host computer.

Note that defragmenting does not reclaim unused space on a virtual disk; to reclaim unused space, shrink the disk.

It is strongly recommended that you defragment using a guest operating system mechanism before taking the first snapshot (or linked clone).

• Workstation makes all its changes to the redo log, not to the original disk, when you run a defragmenting program on the guest after a snapshot. You lose the ability to defragment inside the original disk forever.

• Every sector that moves is copied to the redo log, making the virtual machine redo log extremely large when the disk is heavily fragmented and you run defragmentation after a snapshot.

I suppose it could. I don't know for sure, since I'm not an expert in this, but...

The VM is running within a single large file. If you have a big file on the host allocated to the guest, from the host the file may not be fragmented. All and good.

But inside the guest, the parts within that file are being accessed all over the place, because it's fragmented within that search space. It would be like having a section of the hard disk that is getting a lot of read/write requests.

It's like having a filing cabinet where one drawer is a mess but contains all the folders S-T. Sure, it has all the right S-T folders, but you have to keep rifling through it to find what you need. Same with the host computer. The container file is one big contiguous file, but it's constantly seeking within it to find the right spot being requested by the guest.

On the other hand, I've rarely seen where fragmentation causes a big problem with access. If it's heavily fragmented, yes, it can benefit from a defrag (I liked mydefrag, personally, but there are others, plus it can run as a screen saver...) Personally, if the guest were heavily fragmented, I'd run a defragger, or run mydefrag (it was the successor to jkdefrag) periodically and it'll maintain it so it's not a chore at all.

It will slow down your Guest, and only significantly your Guest, in the same manner as it would if your server was physical. If the datastore is particularly overused by VMs (say >10-15) and they were very IO intensive then it could make a tiny difference but it's unlikely.