I had a test run here internally in order to make a point about what does, or more specifically "does not", happen when you VMotion/SVMotion a Windows Guest OS (GOS). We wanted to demonstrate that, while VMware is copying the VM to another host/storage, it does nothing about the internal fragmentation of files in Windows.

We felt this was a valuable demonstration as one of the old (1980s) ways to "fix" fragmentation was to copy off the files/backup, reformat the volume, and then copy back/restore. This offered a degree of success, but required taking the data offline in order to get rid of most of the fragmentation. On a side note, backing up/copying fragmented files takes a lot longer than it would on contiguous and ordered files.

Anyway, S/VMotion is such a cool feature because it works on live VMs. So, if the VMDK movement somehow did align/reorder files in Windows, it could be a great solution to Windows file system fragmentation! So here's how we tested...

1. Setup 2 ESX 4.1 Servers with iSCSI storage and vCenter with SVMotion capability.

2. Create a VM with Windows 7 in one of the ESX Server storage (Ex: Storage1) and a 20 GB Thin virtual disk.

3. Using an internal tool, create moderate fragmentation on the virtual disk (80k fragments, average fragments per file around 3.0, around 50% free space).

4. Install V-locity with all features (e.g. defrag, IntelliWrite, etc...) disabled. This is just so we can run a fragmentation analysis and save the reports.

5. Save the "Before SVMotion" analysis report, and then stop V-locity Windows Service (to make sure it is entirely inactive).

6. Using SVMotion move the live VM to the other ESX Server storage (Ex: Storage2).

7. Once the move is completed, restart the V-locity Windows Service and perform a post "After SVMotion" analysis.

8. Save this job report.

We saw what we expected, given VMotion leverages Changed Block Tracking (CBT) technology and is block, not file based. I attached the report, so you can see the side-by-side analysis data, files in Windows are not defragmented in an SVMotion. Now, that's not to say possible fragmentation of the VMDK files themsleves (on VMFS datastores) was not affected, but that's a topic for another post.