Should I defrag the hard drive running on a Virtual Machine?

Question

I know that there is no point (in fact it is a bad idea) to run Defrag on an SSD. What about a virtual machine running on an SSD, should I defrag it's hard drive since it is basically accessing the Hard Drive the same way?

Answer 1

I do defrag my VHDs but for reasons of space, not time:

I use the dynamically-allocated option for VHDs, so they start small and expand as needed. But as the VHD (not necessarily the files) becomes fragmented, it expands to include all of the allocated blocks. Defragging the VHD is the first step to compacting it again.

Answer 2

There is no need to defrag an SSD. A regular hard drive has to spin in order to find (the parts of) files. An SSD is comparable to RAM, all files can be reached with the same delay.

Wikipedia states that "Read performance does not change based on where data is stored on an SSD"

Answer 3

This is my opinion only, I don't have test results to back it up. Here's a rough approximation of how things probably happen:

Real OS:

1. Application asks for data X (fast)
2. OS asks disk driver for data X (fast)
3. Physical disk fetches data X and returns it to OS (slow if fragmented)

Here would be the equivalent chain of command in a VM:

1. VM application asks for data X (fast)
2. VM OS asks data X (fast)
3. VM host asks real OS to get data X stored in virtual disk file (fast)
4. Real OS asks disk driver to get data X (fast)
5. Physical disk fetch data X and returns it to OS (slow if fragmented).

As you can see, in both cases fragmentation only really becomes an issue at stage of the operation where the physical hard drive tries to read the data, and that happens in the real OS, outside the VM context. Prior to that, everything likely happens in memory.

In conclusion, since we know that SSDs do not suffer from fragmentation in the real OS, and that the issue of fragmentation in a VM probably only occur at the last physical step of the operation, I would guess that defragmenting either your virtual OS or the virtual disk file in your main OS would not improve performance on a SSD, while being as detrimental/useless as defragging your real OS is.

Edit: And if that's correct, it's a damn good reason to put a VM on a SSD! On a HDD, fragmentation at any stage (guest OS, virtual disk file, real OS) will break linearity and cause fragmentation at the physical disk step.

Answer 4

Whether your Virtual Machine is accessing data that is stored on traditional magnetic HDD or electronic SSD, Windows NTFS file & free space fragmentation slows down the access speed of applications requesting data. NTFS file and free space fragmentation happens far more frequently than you might guess. It has the potential to happen as soon as you install the operating system. It can happen when you install applications or system updates, access the internet, download and save photos, create e-mail, office documents, etc… It is a normal occurrence and behavior of the computer system, but does have a negative effect on over all application and system performance. As fragmentation happens the computer system and underlying storage is performing more work than necessary. Each I/O request takes a measurable amount of time. Even in SSD environments there is no such thing as an “instant” I/O request. Any time an application requests to read or write data and that request is split into additional I/O requests it causes more work to be done. This extra work causes a delay right at that very moment in time.

Disk drives have gotten faster over the years, but so have CPUs. In fact, the gap between the difference in speed between hard disks and CPU has actually widened. This means that applications can get plenty of CPU cycles, but they are still starving to get the data from the storage. What’s more, the amount of data that is being stored has increased dramatically. Just think of all those digital photos taken and shared over the holidays. Each photo use to be approximately 1MB in size, now they are exceeding 15MB per photo and some go way beyond that. Video editing and rendering and storage of digital movies have also become quite popular and as a result applications are manipulating hundreds of Gigabytes of data. With typical disk cluster sizes of 4k, a 15MB size file could potentially be fragmented into nearly 4,000 extents. This means an extra 4,000 disk I/O requests are required to read or write the file. No matter what type of storage, it will simply take longer to complete the operation.

The physical placement of data on an SSD doesn’t really matter like it does on regular magnetic HDDs. With an SSD there is no rotational latency or seek time to contend with. Many experts assume that fragmentation is no longer a problem, but the application data access speed isn’t just defined in those terms. Each and every I/O request performed takes a measurable amount of time. SSD’s are fast, but they are not instantaneous. Windows NTFS file system does not behave any differently because the underlying storage is an SSD vs. HDD and therefore fragmentation still occurs. Reducing the unnecessary I/O’s by preventing and eradicating the fragmentation reduces the number of I/O requests and as a result speeds up application data response time and improve the overall lifespan of the SSD. In essence, this makes for more sequential I/O operations which is generally faster and outperforms random writes.

In addition, SSD’s require that old data be erased before new data is written over it, rather than just writing over the old information as with HDDs. This doubles the wear and tear and can cause major issues with the speed performance and lifespan of the SSD. Most SSD manufactures have very sophisticated wear-leveling technologies to help with this. The principle issue is write speed degradation due to free space fragmentation. Small free spaces scattered across the SSD causes the NTFS file system to write a file in fragmented pieces to those small available free spaces. This has the effect of causing more random I/O traffic that is slower than sequential operations.

I have benchmark results to back this up. If you want, post a comment, requesting these results, and I'd be happy to share them with you.

Answer 5

With regards to the original question of a traditional defrag of an SSD, I do agree it is a bad idea, but there are specific solutions available that address the concerns of file movement and SSD lifespan.

A virtual machine that is running Windows as its operating system, fragmentation will still occur and the combined effect of the extra I/O traffic will reduce the speed and efficiency of not only the guest systems, but that of the host as well. Both Microsoft and VMware recommend the need to address fragmentation at the guest level.

Here’s why…

1. Application asks for data X

2. Request is processed by NTFS.sys

3. The file attributes are examined ($MFT) and if the data is not contained in a single extent (fragment) then additional I/O requests are created for each extent/fragment to satisfy the original data request.

4. Each of these requests are then sent to the disk storage driver.

5. Once the data is retrieved it is passed back up the stack to the user/application.

Each Windows virtual machine is sending this type of I/O traffic to the Host system. If the file system structure is fragmented at the Guest/Virtual machine level then this translates into additional and unnecessary I/O traffic having to be handled by the Host and farmed out the backend storage. This gets further compounded as you add more and more virtual machines. In fact, you can have fragmentation within fragmentation at the host file system level.

Whether the data is stored on an SSD or a traditional HDD, if you are running Windows the NTFS file system will become fragmented and as a result you will never achieve the manufactures rated speed and throughput due to NTFS file and free space fragmentation. The effects can be measured via PerfMon by looking at Average Disk Read Queue Length, Average Write Queue Length, and most importantly Split IO/Sec.

Answer 6

Starting with Windows Server 2008 and Windows Vista, be careful with Windows default scheduled defrag task.

It can be disabled with : schtasks /change / tn “microsoft\windows\defrag\ScheduledDefrag” /disable

or using PowerShell:

Get-ScheduledTask ScheduledDefrag | Disable-ScheduledTask

Extracted from: http://www.sysadmit.com/2015/10/vmware-y-gpo-defrag-windows.html

Answer 7

I've just defragmented a VMLite XPMode VM using windows defrag hosted on 240Gb INTEL SSDSC2CW240A3.

Pre Defrag VM size on host - 7.83Gb (Used space on C: on VM, 5.81Gb of 121Gb)

Post defrag - 9.86Gb (Used space on C: on VM, 5.80Gb of 121Gb)

Not the result I expected and I have restored the pre defrag version.

Answer 8

No, not really. There are stuff like "Hyperfast" by Diskeeper, but I have no idea how efficient these technologies are. (It's maybe just a ripoff so they won't fall off the market after SSD will become mainstream.)