those technologies will be used. If you are using a SAN and that SAN supports
offloaded data transfer (ODX) and a virtual machine is being moved within a single
LUN or between LUNs, ODX will be utilized, which will mean that the move uses
almost no load on the host and will complete very quickly.
The SAN ODX scenario is the best case. For all of the other cases, it is important to
realize exactly what an unbuffered copy means to your system. The unbuffered copy is
used because during the storage migration it would not be desirable on a virtualization
host to use a large amount of system memory for caching data. Performing a copy can
cause a significant amount of I/O load on your system, for both reading the source
and writing to the target.
To get an idea, try a manual unbuffered copy on your system by using the xcopy
command with the /J switch (which sets the copy to unbuffered). That is similar to
the load a storage migration would inflict on your system (once again considering the
ongoing mirrored writes as fairly negligible). Consider, therefore, moving a virtual
machine between folders on a local disk, likely a worst-case scenario. The data would
be read from and written to the same disk, causing a huge amount of disk thrashing. It
would likely take a long time and would adversely affect any other virtual machines
that use that disk. That is a worst-case scenario, though. If the source and target were
different storage devices, the additional load would not be as severe as a local move
but would still need to be considered.
There is nothing Hyper-V specific about the disk I/O caused by moving a VM. It would
be the same for any data migration technology (except that other technologies may
not have capabilities like ODX if a SAN is involved); ultimately, the data has to be read
and has to be written. This does not mean that you should not use storage migration,
but it does mean that you should plan carefully when you use it. It’s not something
you would likely want to perform during normal working hours because of the
possible adverse effect on other loads, and I suspect that’s why at this time there is no
automated storage migration process as part of the Dynamic Optimization in System
Center Virtual Machine Manager that rebalances virtual machines within a cluster. If
you detected a large I/O load on a storage subsystem in the middle of the day, the last
thing you would want to do is to add a huge extra load on it by trying to move things
around. The best option is to track I/O over time and then at a quiet time move the
virtual machines’ storage, which would be easy to script with PowerShell or automate
with technologies like System Center Orchestrator.
There is no specific configuration to enable storage migration. As previously stated,
storage migration uses whatever path exists to communicate with the source and
target storage and is enabled by default (in fact, you can’t disable it). The only
configuration is setting how many simultaneous storage migrations are allowed, and
this is configured via the Hyper-V Settings action in the Storage Migrations area.
This can also be configured using PowerShell:
Set-VMHost -MaximumStorageMigrations <number to allow>