Surereplica or surebackup failed as vLab in use errors

[zadrian]

HI....I have quite a few VMs being both replicated (from HQ to Site-1) and backup (within site-1) thus there are quite a few surebackup & surereplica jobs running in site-1 (3x ESXi hosts, 6.7u3, using full local SSDs).

The jobs in HQ are run in the following sequence : Reverse Increment (stored in HQ-NAS01) > backup copy (stored in HQ-NAS02) > backup copy (stored in site1-NAS01) > replication (from site1-NAS01 to site1-ESXi). Then a fixed time set to run surereplica.

The jobs in site-1 are run in the following sequence : Reverse Increment (stored in site1-NAS02). Then a fixed time set to run surebackup.

Each VM have its own job and its own application group (no more than 2 VMs per application group), this was recommended by vendor.

The problem is that some of the OS take a long time to boot (I set time out to 6000s, else some may have time out errors) and the surereplica and/or surebackup cannot be scheduled subsequently. So if one job over runs, I get the "job failed as virtual lab in use".

Is there a way such that I can create 2 or more virtual labs per ESXi host and like "cluster" the surebackup or surereplica jobs to use any virtual labs that are free ?
Else is the "creation of one VM per application group" correct ?

[PetrM]

Hi Zadrian!

Would you be so kind to clarify why does vendor recommend to start 2 VMs maximum in application group?
I'd suggest to add all critical VMs into a single application group so that you have just one verification (SureBackup/SureReplica) job and just one virtual lab.

By the way, you may use link job option for those VMs which do not run infrastructure-critical services.

Thanks!

[zadrian]

PetrM....The reason is such that if one VM have issues, the whole job will not fail....

For example, there is a VM that have a very large SQL and sometimes the surereplca gets timed out (OS or application failed to start in allocated time of "6000s") then the rest of the VMs are stopped.

It is like one bad apple and we chop down the whole tree ?

[PetrM]

Yes, it's disappointing when the whole job is failed if some VM gets timed out however it might be worth checking the behavior with increased timeouts, for example up to 20 min?

On the other hand, if you know specific VMs which are affected, probably you could create an additional application group and verify these VMs in a dedicated job, and retry it in case of failure?
Other "stable" VMs can be started in another application group which is added in another verification job and this job uses link job option.
You will have just 2 verification jobs which run consistently.

Thanks!