- 1 An Azure Lexicon for Working with Virtual Machines in Microsoft Azure
- 2 Creating Azure Virtual Machines Quickly and Painlessly
- 3 Tips and Considerations When Creating Virtual Machines in Azure
- 4 The End of the Road for Windows Server 2003 and 2008
- 5 Move-VM, Move-VMStorage and Compare-VM PowerShell cmdlets for Hyper-V
Troubleshooting Generic and Known Error Messages in Hyper-V Replica
When writing code to develop a software application, the programmer needs to make sure that all known error messages are captured and displayed when a specific condition occurs. A programmer needs to think about all the possibilities when dealing with a failure event.
For example, writing a network communication code requires that the code starts with a ping routine and then continues to execute the other routines. Based on the results returned from the ping routine, the next function/routine is executed. In case of any error returned while executing the code, the programmer needs to return either a generic or known error message.
A known error message is defined in the code and shown when a failure event occurs and the cause of the failure is "known." An unknown error message (a "Generic" message), on the other hand, is defined in the code and is shown when a specific condition fails and the cause of the failure is "unknown." In any case, it is imperative to show an error message (Generic or Known), which can be helpful in further troubleshooting.
Microsoft's Hyper-V Replica has been designed the same way. In the case of any failure event, a generic error message is shown if a known error message is not applicable.
Sometimes, though, it can be difficult to troubleshoot the issues with Hyper-V Replica based solely on the generic error messages. This tutorial will explain how to troubleshoot generic error messages and what you should do when a known error message occurs. Hyper-V Replica may generate the following generic and known error messages:
- Known Error Message: Hyper-V prevented starting the virtual machine because it is prepared for failover.
- Generic Error Message: Hyper-V is not in a state to accept replication on Replica Server for virtual machine <VM Name>.
- Generic Error Message: Failed to perform the operation. Hyper-V is not in a valid replication state to perform the operation.
- Known Error Message: Hyper-V failed to resolve the Replica Server name.
- Known Error Message: Hyper-V prevented starting virtual machine because replication is ongoing.
Known Error Message: Hyper-V prevented starting virtual machine because it is prepared for failover
You might get hit with this error message, as shown in the below screenshot, when you are trying to start the Primary Virtual Machine.
The error message says "Hyper-V prevented starting the virtual machine because it is prepared for failover." This is a Known error message because the cause for the failure is known. Please note that a virtual machine for which the "Planned Failover" has been initiated is turned off at the Primary Server and turned on at the Replica Server if you selected to do so.
Such virtual machines cannot be turned on at the Primary Server unless replication is broken or the reverse replication is initiated. This is expected behavior from Hyper-V Replica and can be safely ignored.
Generic Error Message: Hyper-V is not in a state to accept replication on Replica Server for virtual machine <VM Name>
You are trying to enable replication for a virtual machine and get hit with the generic error message as shown in the below screenshot.
Before we discuss the resolution of this error, let's understand what happens when you enable replication for a virtual machine. When you enable replication or hit the "Finish" button in the wizard, the Primary Server creates a pointer for the virtual machine on the Replica Server. This virtual machine is created with the same "GUID" and same name as the Primary Virtual Machine.
Before it creates the Replica Virtual Machine, the Primary Server checks to make sure there are not any other virtual machines configured with the same GUID on the Replica Server. If it finds any virtual machine already configured with the same GUID, the above generic error message will be displayed.
The above error message does not specifically say that a virtual machine with the same GUID is already present on the Replica Server but instead returns the generic error message, "Hyper-V is not in a state to accept replication on Replica Server for virtual machine <VM Name>." To resolve this, you must delete the virtual machine on the Replica Server and its associated files before you can enable the replication.
Note: A virtual machine with same GUID can exist on Replica Server only if replication was enabled previously for the virtual machine and then was later removed administratively.
In the current version of Hyper-V Replica, the Primary Server does not ignore if a virtual machine is already configured on the Replica Server. While Microsoft might update the Hyper-V Replica engine to include a mechanism that helps in fixing such issues, as of today it does not!
Generic Error Message: Failed to perform the operation. Hyper-V is not in a valid replication state to perform the operation
In the case of any maintenance activity at Primary Server, "Planned Failover" is initiated to bring the virtualized workloads at the Replica Server. Reverse replication action is performed from the Replica Server in which the Primary Server performs the role of Replica Server and vice-versa.
You could get hit with a generic error message if you execute the "Reverse Replication" action from the right-click context menu of the Replica Virtual Machine. When you hit "Finish" in the "Reverse Replication Wizard," you could see this error message: "Failed to perform the operation. Hyper-V is not in a valid replication state to perform the operation," as shown in the below screenshot:
Since there are multiple reasons associated with the error message as to why it failed, a generic error message is shown. To resolve the issue, consider the possibilities below:
- The Primary Server is not configured as a Replica Server. The Primary Server must be configured to accept the replication. In other words, replication must be enabled on the Primary Server so that the reverse replication action can be successful.
- Firewall rules are not enabled on the Primary Server. In the case of normal replication from Primary to Replica Server, firewall rules are enabled at the Replica Server. In the case of reverse replication (e.g. from Replica to Primary Server), you must also enable the firewall rules at Primary Server.
Known Error Message: Hyper-V Failed to resolve the Replica Server name
This is a "Known" error message in the Hyper-V Replica code that indicates an issue with the name resolution. You might see "Hyper-V failed to resolve the Replica Server name" error message when enabling replication for a virtual machine or when using the reverse replication wizard as shown in the below screenshot.
The possible cause is that you have either entered the wrong server name or entered an IP Address or NetBIOS name of the destination Server when the wizard is expecting the name to be in FQDN format.
Known Error Message: Hyper-V prevented starting virtual machine because replication is ongoing
When a virtual machine is enabled for Hyper-V replication, the Replica Virtual Machine at the Replica Server is turned off and the Primary Virtual Machine continues to run on the Primary Server. If you try to turn Replica Virtual Machine on, a Known error message is returned which is shown in the below screenshot:
This is expected behavior from Hyper-V Replica. You can not turn Replica Virtual Machine on if a replication is ongoing or if replication is enabled. You would want to turn Replica Virtual Machine on only after a failover from Primary to Replica Server has been initiated or if the replication is broken.
Nirmal Sharma is a MCSEx3, MCITP and Microsoft MVP in Directory Services. He has specialized in Microsoft Technologies since 1994 and has followed the progression of Microsoft Operating System and software. In his spare time, he likes to help others and share some of his knowledge by writing tips and articles on various sites and contributing to Solution IDs for www.Dynamic-SpotAction.com. Nirmal can be reached at firstname.lastname@example.org.
Read more on "Server OS Spotlight" »