Virtual machine migration operation failed at source. An existing connection was forcibly closed

  • Article

I have recently been working on a project that involves migrating VMs between clusters. This project came about due to a desire to upgrade the storage and host hardware within the infrastructure.

We investigated the possibilities of using Failover Cluster Manager to migrate the VMs/Roles between clusters, however in this instance that method did not fit, due to the method requiring that the old storage be mapped to the new hosts (not possible due to hardware restrictions), also perhaps more importantly this method would incur downtime!

In addition to the environment being a mature Hyper-V estate, we were also very fortunate that the customer had previously chosen to centrally manage their environment using SCVMM 2012 R2. Within VMM, since SP1, we have the ability to perform cluster-to-cluster Live Storage Migrations, also referred to as "Live (VSM)" during the wizard. (AMAZING, I know!). For more details see: https://technet.microsoft.com/en-us/library/jj628158.aspx

So using the Live (VSM) feature in VMM we attempted to migrate a single VM, which worked perfectly. We then set about migrating further machines, however after 3 successful migrations, the 4th FAILED!. We attempted the same migration shortly after and it COMPLETED! whilst working through the list of VMs we saw a number of RANDOM failures, all producing the following error (Error (12700)):

The same error may also appear when attempting a Storage Migration using the Hyper-V Manager console:

Whilst investigating the error messages, I found that the Live Migration authentication method was set to CredSSP, instead of Kerberos (see for details: https://technet.microsoft.com/en-us/library/jj134199.aspx). After configuring all hosts with Constrained Delegation, we no longer received the above error when performing Live (VSM) migrations, in VMM, between clusters.

Although the initial issue had been resolved, we were left with another....(see for details: https://blogs.technet.com/b/virtual-mite/archive/2014/09/11/duplicate-vms-created-on-destination-during-cluster-to-cluster-migration.aspx)