During an Exchange 2016 to Exchange 2019 migration, no mailboxes could be moved to the new Exchange 2019 databases. The MoveRequests got stuck at 0% and showed the error StalledDueToSource_DiskLatency:
No matter how large or small the mailbox was: No mailbox could be moved. Directly after creating the MoveRequest, the error StalledDueToSource_DiskLatency was displayed. Even after a longer wait, the status did not change. The following command provided a hint as to what could be the cause of the problem:
Get-MoveRequest | Get-MoveRequestStatistics -IncludeReport -Diagnostic | fl
The error report indicates a problem with the storage and also directly shows the corresponding volume, which has too high a latency:
The volume from the error report is the volume that stores the database:
I then checked the performance values of the volume (Windows performance counter, vmware performance counter, storage values), but could not find any problem. This Exchange Server was a vmware VM with sufficient storage on a dedicated datastore. The vmware datastore is located on a high-performance Pure All-Flash Array. All latencies that I could find, from the storage to the VM, were unremarkable and delivered values of less than 1ms.
The troubleshooting here was quite frustrating, all performance counters delivered optimal values, there was no indication of a performance problem. Moving the VM to other datastores from another storage array did not help either.
Due to an older storage migration of the Exchange Server, however, there was an inconvenience: The volumes for the databases were spread over several disks (spanned volumes). This can be seen in this screenshot, where a volume spans several disks:
As already mentioned, the performance counters of each individual disk were also unremarkable, but this was the last straw. So I dissolved the spanned disks and configured a large simple volume for the database. Fortunately, there was enough free space on the storage and, thanks to virtualization, the database move was completed quickly. Spanned volumes and Exchange servers are actually not that unusual. With a physical server with a JBOD, the procedure would be similar.
After the database volume was saved again on a large disk with a volume, the StalledDueToSource_DiskLatency error disappeared. All mailboxes could be migrated without any problems. Also for other databases which were stored on spanned volumes, the migration of the mailboxes worked after switching to a large disk. The StalledDueToSource_DiskLatency error did not occur again afterwards.
By the way, I created the large single disk for the database on the same storage and the same vmware datastore. Ultimately, I could not determine the reason for the StalledDueToSource_DiskLatency error, but it seems to be related to the Spanned Volumes.
Perhaps this will also help others, if you have already had this error, please write it in the comments.