How to Fix Misleading Drive Size When Implementing Azure Site Recovery
While conducting an implementation of Azure Site Recovery (ASR), I ran into an interesting problem regarding operating system (OS) disk size. The problem was not evident in the prompted error messages or the obvious locations where the disk size is displayed.
The Technology
The Source Virtual Machine
The source virtual machine being replicated to Azure was a Hyper-V Gen2 Windows 2012 R2. The OS disk VHD size in File Manager displayed as 60GB. The size of the disk in Disk Management displayed as 299.88GB. The OS VHD displayed as 55.54GB in File Manager.
The Target Virtual Machine
The target virtual machine was being replicated to the Azure Central US region.
The Problem
The virtual machine replicated from on-premises to Azure without errors during the pre-check or actual replication. The problem arose when a test-failover was attempted from the first Azure region to a second. During the test setup the disk size for the OS disk displayed as 300GB. Since this was the first time that the new test failover feature was being attempted, it was assumed that 300GB was the limit size.
The Error
The test failover started to run but then failed after two minutes producing the error. None of the six items listed were the cause and the OS VHD size was under 300GB. Nothing seemed to meet the criteria for the error that was produced.
Escalate to Microsoft Support
To overcome the issue, a ticket was opened with Microsoft support. The team at Microsoft observed the backend while I re-ran the Test failover. They were able to see an error message that stated the error was due to the VHD size being over 300GB.
As stated earlier, the OS VHD size was 60GB. So this error did not make sense. In the end, it turned out to be referring to the size of Disk0.
Taking a deeper look into Disk0, it was discovered that the actual size was 306.67GB — obviously over the 300GB limit. So why didn’t the error message accurately convey this? Clearly the error was captured on the backend side that Microsoft has access to, why not provide the message to the customer?
The Resolution
To combat the issue, the volume of Disk0 was shrunk down to 289GB. As a result, the test failover operation ran correctly and completed, and the actual drive size now displayed correctly. The 300GB changed to 289GB, thus reflecting the actual size.
The Takeaway
There are two takeaways from this exercise: first, whenever you are at or near a specified limit and you run into issues, take a very close look at your numbers because they are not always what they appear to be. Second, take error messages with a grain of salt. The message that you receive may not be 100 percent accurate or related to the issue that you’re experiencing.