Hyper-V on RAID is Slow…Why?

Why Hyper-V May Be Slow on a RAID

Striped RAID combines several hard drives into one by storing consecutive blocks on the next hard drive in the array.

For example, if you use four hard drives in a striped array block #1 and #5 are on hard drive #1, block #2 and #6 are on drive #2.

Now, whenever you copy files this arrangement is quite efficient because the OS will read block after block in sequence and the RAID controller can load the next four blocks simultaneously, giving you the multiplied (4x) speed you’re looking for.

However, Hyper-V virtual disks often store VMs with Exchange and SQL Server and other block oriented, random access services.

Understanding random access is the key here. Random access means the system won’t necessary read blocks in sequence; hence, your actual throughput may be no better than when using a single hard drive.

How can this be? The striped RAID arrangement assumes sequential access, block after block. Only then can it give you a useful speed improvement. When the system reads block #1 followed by #101 and both are on the same disk, it can’t possibly speed things up. In addition, RAID controllers may be reading one entire stripe at a time, which is usually a multiple of 4KB to optimize for modern hard disk sector size.

However, the older VHD format is using 512 sectors and Hyper-V may be “jumping” randomly within a VHD in 512 byte steps. In some RAID settings an entire stripe may have to  be read due to the way the RAID is managed internally. This means it can happen that all four drives are engaged to read a tiny fraction of a block from hard drive #3.

What to do

Three major factors in Hyper-V make things worse:

1. Using dynamically expanding disks. A big no-no if you want performance. Expanding disks will cause the disk heads to move like crazy eventually because virtual disk blocks aren’t really stored sequentially on disk
2. Using checkpoints aka. Hyper- V snapshots. Those result in differencing disks which also require additional ‘jumps’ from one disk sector to another. Those head movements are extremely time consuming
3. Disk fragmentation, mostly caused by the above two items. As dynamic expanding virtual disks grow they cause fragmentation on the host as well. More file fragments means more time wasted jumping from sector to sector, and there’s time wasted in looking up where the next block is actually stored on disk, too.

The recommendation is hence:

1. Don’t use dynamically expanding disks
2. Don’t use Hyper-V Checkpoints / Snapshots
3. Use fixed sized VHDX over VHD to get 4KB block alignment
4. Don’t make the RAID stripe too long
5. Defrag the host before creating the VHDX
6. Consider whether a bunch of small, two hard drive mirror RAIDs using fast hard drives may be a better choice
7. Use SSDs? Those may be less reliable and much more expensive but they eliminate the expense of hard disk head movement. However they aren’t as reliable as magnetic media and the CPU time would still be an issue when using differencing or expanding disks. Yet the CPU overhead is much smaller than the time required for a mechanic drive to move its heads

Try BackupChain to back up Hyper-V