Replication causing VM to go in to saved state

[DarrenD]

Hi,

We've had a case open for a while now ( 00826852 ) where Veeam V8 runs a backup job of a 2008 R2 Hyper-V cluster, and also tries to run a replication job to another 2008 R2 Hyper-V host.

The backup job runs fine and as expected.

The replication job 'works' but in an unusable manner, in that when it snapshots the VM it puts it in to a saved state, snapshots, then restarts it. This isn't acceptable.

Working with Veeam support hasn't got us anywhere so far despite their best efforts, and it's a slow process from our side as we need to find a suitable time to test where taking the VM down won't impact too much!

This worked fine with V7 and I've got a customer on my back! Any help gratefully received!

Thanks,
Darren

[Vitaliy S.]

Does the backup job for this VM have the same settings as replication job? In some cases VMs are indeed backed up via saved state.

[DarrenD]

Hi Vitaly,

Yes, the job has the same settings as far as I can tell.

[foggy]

Darren, please ask for the case escalation. This looks like a known issue with logs truncation logic, support should be able to configure your job to lower the probability of its occurrence. Btw, this is addressed in the upcoming Update 2.

[lmbarrett83]

I know it is not a fix but could you use the new feature that allows you to replicate using backups as your source as opposed to the live VM state?

We have recently implemented this feature to reduce the load on our production csv.

We too had issues but all seem to have been ironed out now (veeam fix) and it's working quite well.

If your backup is running ok it may serve as a useful workaround.

[DarrenD]

Looks like this has been resolved by adding the registry key HvSleepAfterGuestInstalledSec and setting it to 90s.

Not sure why it would only affect the replication and not the backups, but it's working so customer is happy!

Fingers crossed!

[foggy]

Thanks for getting back with this. Btw, what Lewis has suggested above, makes total sense and allows to avoid touching your production VMs twice.