VMware Cloud Community
DanieleFiore201
Enthusiast
Enthusiast
Jump to solution

Synch RPO violation

Dear guys,

i'm replicating a VM using vSphere Replication and since a while i'm getting the following error :Synch RPO violation.
I have set RPOs to 3 hours.

One question : can i start recovering a VM when i have such error ?
The things is sometimes replica is fine and i have all green and sometimes i have this error message but i need to be able to recover my VM anytime.

Any suggestion ?

Many thanks in advance.

Daniele

0 Kudos
1 Solution

Accepted Solutions
mmarinov
VMware Employee
VMware Employee
Jump to solution

As you probably know the changes are replicated between source and target based on the provided RPO - 3 hours in your case. This means that if you power on the VM on second hour your changes won't be replicated since powered off machines are not replicated. If you manually initiate sync the changes made in the first 2 hours will be replicated. This will be done if you start recover wizard the first option is with sync which will replicate those changes as well if the source VM is powered off.

Martin Marinov VMware Software Engineer If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

View solution in original post

0 Kudos
8 Replies
mmarinov
VMware Employee
VMware Employee
Jump to solution

Hi Daniele,

Sync RPO violation status means that during sync operation is in progress VR hasn't reached the defined RPO (in your case it is 3 hours). Several reasons could lead to this state - network connectivity between the sites, network issues with the host and/or datastore, a lot of changes need to be sync but your network is overloaded , etc.

In order to recover a VM replicated with VR it is required to have the initial full sync completed to the target site, e.g. in the VR UI the last completion time, duration and columns must be filled with the correct values. The recovery operation exposed as a button over the replication list is enabled in the cases when you are not allowed to recover - such as recovering is already in progress, moving the replication (if you are using VR 5.5) from one replication server to another, still in configuring state, etc.

Hope this helps.

Regards,

--Martin

Martin Marinov VMware Software Engineer If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points
0 Kudos
DanieleFiore201
Enthusiast
Enthusiast
Jump to solution

Hello Martin,

many thanks for your helpful answer, i will file an SR to VMware but what i do not understand is the following :

- at the moment i'm replicating a OES 2 VM that is doing nothing as still not productive and the amount of data replicated is growing , 3 hours ago 580 MB, now last replica is almost 1GB

Can you figure out where this coming from ?

0 Kudos
mmarinov
VMware Employee
VMware Employee
Jump to solution

Hi Daniele,

As I replied the size of replicated data could be an issue but it could be not. You can go the VC where the VM resides on and look at the events for this VC posted by VR. There you can probably see a network issue. The issue however could be at the target site where you can troubleshoot it the same (through events' view) way in the VC.

Having the state changed to OK means that the traffic is back to normal from source to target and this is the behavior of VR. I'm not sure what this SR will be about.

Regards,

--Martin

Martin Marinov VMware Software Engineer If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points
0 Kudos
DanieleFiore201
Enthusiast
Enthusiast
Jump to solution

Ok many thanks for the hint.

Another question : if i recover the VM , how can i go back to the previous situation ?
Can i simply shutdown the recovered the VM and start the original VM  ?

0 Kudos
DanieleFiore201
Enthusiast
Enthusiast
Jump to solution

Hi i think i found it

VMware vSphere 5.1

0 Kudos
mmarinov
VMware Employee
VMware Employee
Jump to solution

If you recover a VM not in case of disaster the source VM must be powered of. In this case there is no replication between source and target. Once the target is recovered - it is the same.

However if the source and target are powered on then you can probably have a lot of issues - such as IP duplication.

After recover you can turn down the recovered VM and start the source VM but all the changes made in the recovered VM won't be replicated.

Regards,

--Martin

P.S.: In order to have better maintainability of the community it will be better to ask questions in different discussions.

Martin Marinov VMware Software Engineer If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points
0 Kudos
DanieleFiore201
Enthusiast
Enthusiast
Jump to solution

Hi Martin , you are right sorry for too many questions but then i have a question about what you wrote : "In this case there is no replication between source and target"

I just made a test powering off the source VM and i wanted to recover the VM on the destination but i had no "recover VM" option but there was the option sync now.
I clicked on sync now and it is taking a while now, but the question is if the source VM is off what is replicating actually?

0 Kudos
mmarinov
VMware Employee
VMware Employee
Jump to solution

As you probably know the changes are replicated between source and target based on the provided RPO - 3 hours in your case. This means that if you power on the VM on second hour your changes won't be replicated since powered off machines are not replicated. If you manually initiate sync the changes made in the first 2 hours will be replicated. This will be done if you start recover wizard the first option is with sync which will replicate those changes as well if the source VM is powered off.

Martin Marinov VMware Software Engineer If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points
0 Kudos