It should be fine unless you're using the performance and resource optimization features, but I would not consider it a "supported" configuration.
Is there any reason you cannot remove them from the original SCVMM and then add them with the external server, with no period of overlap? If you're just trying to save time, near 100% of the capabilities of SCVMM can be accessed, although less efficiently, through a combination of the Hyper-V Manager and Failover Cluster Manager, in the case of clustered scenarios.
Great question!
The most likely reason for the RPC failure is that the cluster name resource (and IP address) were likely hosted on the server whose primary network connection was flapping.
Since the interface was going up and down, access to the cluster via the cluster name would likely fail due to the network interruptions.
You should be able to execute commands against the cluster from the command line (either cluster.exe or the FailoverClusters module in PowerShell). The FailOverClusters module can be used over PowerShell remoting if the appropriate credential delegation is configured (either CredSSP or Kerberos).
In the case of a failure of the network interface hosting the cluster name, you could use PowerShell to move that cluster group to one of the nodes that is accessible, or you could just execute commands against the cluster to migrate machines, etc..
To ensure that this does not happen again, you likely will need to make the NIC highly available (NIC teaming). This is dependent on where you are managing the cluster from.. one of the servers or a remote management station. If you are managing from a cluster machine in that same cluster, you could add an IP on the cluster network to the cluster name, but you would want to make sure that was not added to DNS, otherwise you might interrupt remote management clients from being able to connect.
To add an IP Address to the cluster group via PowerShell -
$Resource = Add-ClusterResource -Name SecondaryIP -ResourceType "IP Address" -Group 'Cluster Group'
$Resource | Set-ClusterParameter -Name 'Address' -Value 'Your-IP-Here'
$Resource | Set-ClusterParameter -Name 'SubnetMask' -Value 'Your-SubnetMask-Here'
You'll need to disable dynamic dns registration and create static entries if you don't want remote management clients trying to talk to the private network.
Best Answer
I have moved several DCs in the way you described and it works rather well. Don't forget to remove the old network interface after re-creating the VM on the new host.