Posted by: Eric Siebert
defrag, Eric Siebert, ESX, virtual disk, VMware
There’s an ongoing debate about whether or not VMware users should defragment virtual machine disks. We’ll answer this question in two parts: the first part will cover virtual machine (VM) disks inside a guest operating system. The second part will cover VM disks outside of a guest operating system that reside as a large file on a host machine’s VMFS data store.
Should you defrag a VM’s disk at the guest operating system level? The answer is yes. If a virtual machine disk is excessively fragmented, you should treat a VM’s disk just as you would a physical server and defrag as necessary.
If you do defrag your VM’s disk, then you should be aware of a few things. First, a defrag operation causes high disk I/O on your host server so it is best to perform a defrag during off hours or when disk activity is low on your host. You should also try not to defrag too many VMs on a host simultaneously as this can really drive the I/O up on your host server, which could slow down other VMs on the same host, or even on other hosts that have VMs on the same storage as the VMs being defragged. Finally, you should never defrag a VM’s disk if the VM has an active snapshot. While this will not cause any harm to the VM it will make your snapshot file grow rapidly as many disk blocks are being modified. It will also severely decrease LUN performance because every time a snapshot grows in 16 MB increments it causes a SCSI reservation which briefly locks the LUN.
So should you defrag your host’s VMFS volumes? The answer is no, for two reasons. First, it is not possible as there are no built-in or third party utilities available to execute the operation. The second reason is that the host VMFS data stores do not really fragment because of how virtual disks write to the VMFS volume. That’s not to say a VMFS volume cannot become fragmented at all. They do, but not to the extent that traditional OS disks become fragmented. This is because a standard OS can consist of many thousand of files that are fairly small in size, and a VMFS volume contains mostly very large virtual disk files.
When a standard thick disk is created for a VM all space on the disk is allocated at once, which results in the disk having mostly contiguous space. There are some exceptions to this. If you manually create a thin disk on a VMFS volume it will grow on demand which can result in fragmentation as the blocks are written to different free spots on the physical disk. Also, if you copy a disk file to a VMFS volume using a utility like SCP the space is allocated as the file is copied and not all at once. The proper way to import or copy a virtual disk file to a VMFS volume is to use the vmkfstools utility which allocates all space at once before the copy is made.
Over time, a VFMS volume can become fragmented as VMs and snapshots are created and deleted, and other smaller files like the vswp files and log files are also created and deleted. These changes result in new VM disks that do not have contiguous space. But this typically isn’t a problem because even though the disk blocks are no longer contiguous, they are still split up among several very large contiguous spaces which results in a disk that has minimal fragmentation.
In short, go ahead and defrag your VMs’ disks if they becomes fragmented, and don’t worry about your host’s disk, which will not fragment like traditional disks do.