Hyper-V Program Manager
A common question I get asked about storage migration is “how does it perform?”
This question can actually be broken into two components:
Let’s tackle these sections separately.
First up – how long does it take to move the virtual machine?
As I have discussed, at the core of storage migration is the combination of a single file copy of the virtual hard disk that is being moved, combined with duplicating incoming virtual hard disk writes. This approach means that the actual length of the storage migration depends on the amount of activity that is happening inside the virtual machine. The more data the virtual machine is writing to its storage, the longer the storage migration will take. For a virtual machine that is mostly idle (with little disk activity) the amount time that it takes to complete a storage migration is going to be similar to the amount of time it takes to perform an unbuffered copy of the same files.
I highlighted the word “unbuffered” because most of the time people perform buffered file copies. If you just copy a file in Windows explorer – you are doing a buffered file copy. These copies tend to be faster, but they utilize more system resources to do so, and are not recommended when copying very large files. You can do an unbuffered file copy manually in Windows by using the command XCOPY /J. This should give you a good idea of the amount of time that will be involved in using storage migration.
Now for the second part – how does performing a storage migration effect the rest of the system?
Assuming that you are migrating your storage to a new physical disk (or a separate SAN or SMB share) the impact is surprisingly small.
If you imagine a running virtual machine, with reads and writes happening to its virtual hard disks, storage migration will add the following activity:
With all of that said – the performance impact of a storage migration is pretty bad if you migrate to another location on the same disk. If you think through this scenario (storage migration with a source and destination location on the same physical device) you will essentially be doubling the write operations on the disk, and performing a large unbuffered file copy at the same time.
All this to say – if you are interested in assessing the performance of storage migration – do not test it with a storage migration where the source and destination locations are on the same physical disk. Instead, use it like it is intended to be used and storage migrate between separate physical devices.
nice info about the unbuffered copy