I’ve been working on replicating a bunch of Virtual Machines from Hyper-V to Azure for disaster recovery. They all replicated fine apart from one which just didn’t want to play ball.
When I looked at the Error Details in the Azure Portal, I was actually getting 3 different error messages. Here they are in full for the benefit of search engines 😊
- The configuration file for virtual machine ‘server01’ could not be sent to the Azure Site Recovery. You may not be able to failover back your virtual machine on your host if it gets deleted from the host. (Virtual Machine ID b57e8200-6e3d-4ec9-8137-5ac6aae86064 , Data Source ID 17593609955334, Task ID c5475be2-b8b4-4b81-a55f-297863f23d85)
- The configuration file for virtual machine ‘server01’ could not be sent to the Azure Site Recovery because it is greater than the size limit of 24 MB. You may not be able to failover back your virtual machine on your host if it gets deleted from the host. (Virtual Machine ID b57e8200-6e3d-4ec9-8137-5ac6aae86064 , Data Source ID 17593609955334, Task ID c5475be2-b8b4-4b81-a55f-297863f23d85)
- Replication errors occurred for virtual machine ‘server01’ in cloud/site ‘London-DC01’ because of issues with connectivity to Azure storage.
Looking at the Event Logs for Hyper-V Virtual Machine Management Service shows that Hyper-V Replication appears to have enabled replication for the VM successfully though. Which again points to a problem with Azure Site Recovery.
Looking at the MicrosoftAzureRecoveryServices/Replication Event Log on the on-premises Hyper-V server, you get the same errors as on the Azure Portal. I was also getting an extra, fairly generic, error “Replication operations for virtual machine ‘virtualmachinename’ failed. Unspecified error (Error Code ‘80004005’). That didn’t really help much. The error code 80004005 just maps to “Unspecified Error” anyway so wasn’t any help.
The error message said it was due to the size of the config file. The config file of a Hyper-V VM is a .vmcx file within the directory that contains the Virtual Machine. In this case, it is just a little over 2.5MB, definitely not over 25MB.
On the Hyper-V host, there is a log file for the Recovery Services Agent at “Program Files\Microsoft Azure Recovery Services Agent\Temp\CBEngineCurr.errlog”. Looking through the file for WARNING and ERROR message, I found this one which suggests that the problematic configuration file is actually around 35MB:
The Solution
I ended up raising this with Microsoft Support and they came back very quickly with an answer. Essentially Hyper-V replication does an export of the VM to prepare it for replication, then the Azure Site Recovery Provider builds a config file for the VM that will be uploaded to Azure. This isn’t actually the .vcmx file but one specific to Azure. In some cases, this can be significantly larger than the original Hyper-V vmcx file. This VM has much more memory configured than other VMs that successfully replicated, so I wonder if that is related.
The 24MB limit for an uploaded configuration file is the default for the Microsoft Azure Recovery Services (MARS) agent that runs on the Hyper-V host. This can be increased to 256MB with a registry key which can be added with this command (run on the Hyper-V host, not the VM being replicated):
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication" /v MaxUploadConfigSizeInMB /t reg_dword /d 100Go back to Hyper-V Manager, right click the VM, select Replication -> Resume Replication. With any luck the initial replication should now start and some progress will be reflected in 10-15 minutes on the Azure Portal.
