Hyper-V Replica provides protection to VMs by tracking and replicating changes to the virtual hard disks (VHDs) of the VM. Hyper-V Replica runs 24 hours, 365 days in a year; for any VM that has been enabled for replication it ensures that the data on the primary site and the Replica site are kept as closely in sync as supported.
So the status of your Hyper-V replica shows that replication health is critical and if I click resume replication, it says replicating changes >> and after a few moments >> failed.There is no other option to fix this issue. Try these steps:
I know this is an old thread, but complementing the solution provided here and for those looking for a different approach, this is another way of doing it (the PRTG server itself will fetch the replications status, with no PSsessions). You need to enable the Hyper-V Powershell module/provider on your PRTG server/probe. Also, the Windows credential used for this sensor should be a member of the local group "Hyper-V Administrators" on the target servers (either this or a local Administrator), but I believe this is a requirement in any case (I use a GPO to define the prtg user as member of said group). Some PRTG tutorials suggest using a Domain Admin account for everything (which makes it easy), but I obviously don't consider this a good practice.
Sorry, resurrecting an old entry. We are currently using the following to monitor our Hyper-v Replica's. It takes the hyper-v host the replica's are "stored" on as a variable. We currently run this from the probe device. You will need to probably set both the x32 and x64 powershell to at least a remotesigned execution policy for the local machine.
We are dying to get a good replica monitoring. We daily check hundreds of replica statusses....if only prtg had a default sensor for this....It seems quite simple if you are a programmer, but unfortunatley not for me.there are 3 results with hyper-v replica: normal/warning/critical. Seems like a perfect status for green/orange/red....
Hyper-V Replication might be monitored by "Folder" sensor. If HV Replica is working well, then the vhd- and vm-files at the HV Replication's destination folder are updated each time the replication is done, as their "creation time" does. If it isn't working - nothing is changed. Then set up a limit for "oldest file" according to your replication time.
9) Select the initial replication over the next. (if the virtual machine size is in TBs we can save the initial copy on an external media and do a pre seed of the virtual machine. Also select the schedule for the initial replication and click Next.
12) So wait for your replication schedule and once the replication is complete you can verify the health by right click on the Virtual machine>Replication>View Replication health
Over the years, I have developed something of a love/hate relationship with Hyper-V replication. On one hand, replication is one of my favorite Hyper-V features. Since my own production environment is not large enough to justify me building a Hyper-V cluster, I use replication as a way to protect myself against a host-level failure.
The way that Hyper-V replication is supposed to work is whenever a block is changed within a virtual hard disk that is configured for replication, that block is replicated to another host during the next replication cycle. What happens sometimes, however, is that the synchronization process simply comes to a stop.
There is usually a corresponding error message that says, "Hyper-V suspended replication for virtual machine due to a non-recoverable failure. (Virtual Machine ID ). Resume replication after correcting the failure." When this happens, Hyper-V lets you right-click on the virtual machine and choose a Resume Replication command from the shortcut menu. Sometimes this fixes the problem, but other times it is impossible to resume virtual machine replication.
When that happens, there is little that can be done besides disabling replication, deleting the replica and then setting up replication from scratch. This puts the virtual machine at risk until its entire contents can be resynchronized.
So what causes these replication failures? Unfortunately, I don't have a definitive answer. I've searched TechNet for an explanation whenever I have experienced this problem in the past, but have always come up empty-handed. Even so, I think that I might have finally figured out what is going on.
I have been having problems with periodic replication failures for as long as the replication feature has existed. The problems have become far less frequent over time, which I attribute to Hyper-V becoming more mature. Today, Hyper-V replication failures are kind of a rarity (at least in my organization), but I have noticed that there are a couple of things that seem to happen just before a replication failure.
One of the events that seems to trigger a replication failure is a Hyper-V outage. Last fall, for example, I found myself in the projected path of a hurricane. In preparation for the hurricane, I shut down my replica server and stored it somewhere safe. When I eventually brought the server back online, however, I had to deal with an irrecoverable replication failure. I will concede that the timing of this failure could possibly be a coincidence -- but I don't think so.
The other thing that seems to cause replication failures is copying large amounts of data to a virtual machine. About a year ago, for example, I had to copy just under 3TB of data to a virtual file server. Shortly thereafter, the replication process stopped working.
I have long held theories as to why these two types of events might trigger replication failures, but I have always resisted the temptation to write about them because all of the evidence in support of my theories was circumstantial at best. I assumed that the replica was simply being overloaded with replication data, and that replication would fail because the replication process could not be completed within a single cycle. Again, this was just a theory.
This morning, however, I accidentally stumbled onto an interesting TechNet article while looking for something else. The article, which you can read here, lists two reasons why this type of replication failure occurs.
The second reason is that a power failure has occurred on the replica side and the replica server was restarted. The article goes on to explain that data that needs to be replicated can accumulate while the replica server is offline. When the server comes back online, replication fails because the bandwidth is inadequate to handle the volume of data that needs to be replicated.
This explanation seems to fit both of my suspected replication failure triggers. The TechNet article says point-blank that replication can fail if the replica server is disconnected and then restarted. However, it also seems plausible that trying to copy massive amounts of data to a virtual machine could overwhelm the available bandwidth, resulting in a replication failure. Hopefully, this explanation will shed some light on the situation for anyone else who may have been struggling with replication failures.
This script will check first Hyper-V Replica TCP listener on Port 80 because Hyper-V Replica requires HTTP and HTTPS rules to be enabled in Windows Firewall, and then e-mail the Replication State, Replication Mode, the Target frequency of the replica (30 secs, 5 min or 15 min), and how far the replica virtual machine is behind from the primary virtual machine (Delta in min), then the last replication time and the missed replica count used by Virtual Machines which are in Warning and Critical states only in an HTML tabular format to the specified email address.
The error it shows when looking at the replication status is:"Last successful replication for virtual machine 'xxx' has been delayed. Delay has exceeded the defined critical limit. Replication might be encountering problems."
We are also not able to enable replication via the Hyper-V-Manager GUI. When trying to configure, the GUI just flashes endlessly when it checks the configuration after entering the replication server. Configuring replication via Powershell works just fine. Even the initial replication can be executed properly. From then on we are not sure when it fails but it has to happen after a few hours, maximum in a day.
Possibly, it's a performance problem.Whenever I had that problem, too much data needed to be replicated to succeed in the time interval until the next replication took place. That was because I did not exclude the pagefile from replication and it was used heavily.Look at the replication statistics to get an idea about the amount of data.
Replication is a technology that helps you protect mission-critical Microsoft Hyper-V virtual machines. When you replicate a VM, Veeam Backup & Replication creates an exact copy of the VM in the native Microsoft Hyper-V format on the target host. Veeam Backup & Replication maintains this copy in sync with the original VM. Replication provides minimum recovery time objective (RTO) in case a disaster strikes because VM replicas are in a ready-to-start state.
To replicate VMs, Veeam Backup & Replication leverages Microsoft VSS snapshot and checkpoint capabilities. When you replicate a VM, Veeam Backup & Replication instructs Microsoft Hyper-V to create a cohesive point-in-time copy of a VM. Veeam Backup & Replication uses this point-in-time copy as a source of data for replication. 2b1af7f3a8