A replication job exists from our primary to backup site with approx. 20 VMs happily replicating each night.
Backup site is a 2 host vsphere cluster with one of the hosts powered down to avoid wasting power.
Attempts to add another VM to the existing replication job fail during replication, as the initial replication attempts to register the new replica onto the powered off host (I assume because it has a lot less load )
At the moment, our workaround is to power up the 2nd host for the duration of the initial replication then migrate the new replica off to the main backup host before powering the 2nd host off again, however this is a bit of a fudge. Is there a better solution that we should consider?
If remember correctly Veeam is non nondescript when selecting Host and goes for the first in the database, could be wrong though.
Yep, you’re completely right
There is no special logic in choosing host in a cluster. Whenever one is trying to choose a cluster as a target for replication job, the first host in it is picked up.
Thank you for the responses, I'd rather not target a specific host as there is no guarantee the currently powered down host is the host that is always powered down. Targeting the host would then break the nightly replications rather than the more infrequent new VM additions to the job.
Looks like we are stuck with the status quo at the moment, would the same problem affect clusters configured to use Distributed Power Management?
mcwill wrote:Looks like we are stuck with the status quo at the moment, would the same problem affect clusters configured to use Distributed Power Management?
Distributed Power Management will not affect backup server's decision on where to put replica VMs during replication job execution. It can only affect the host selection on actual replica start.
foggy wrote:Distributed Power Management will not affect backup server's decision on where to put replica VMs during replication job execution. It can only affect the host selection on actual replica start.
Foggy I'm not sure I understand this reply, did you perhaps misread DPM as DRS?
As I understand it, DPM will (if resources permit) power down a host to standby within a cluster to save power but have the ability to wake it if it is required. My query was if a remote host is in DPM standby and is then targeted by Veeam, would DPM bring the host out of standby to process the Veeam request?
I realise I could spend some time testing out the above but finding that time is difficult, so I was hoping someone may have some experience with DPM and could advise if this was a feasible alternative before I head down that path.
mcwill wrote:My query was if a remote host is in DPM standby and is then targeted by Veeam, would DPM bring the host out of standby to process the Veeam request?
Well, based on your initial post, DPM does not bring the ESX(i) host from a standby mode when Veeam B&R server tries to run the replication job.
mcwill wrote:Attempts to add another VM to the existing replication job fail during replication, as the initial replication attempts to register the new replica onto the powered off host (I assume because it has a lot less load )
No, we are not using DPM at the moment, currently the host is hard powered off and not under the control of DPM.
The query was IF we configure the cluster for DPM so that VMware is in control of the hosts power state, would that solve the problem we are experiencing of Veeam throwing an error when attempting to talk to a host that is manually powered off.
Thank you for clarification, I'm not sure that we've tested this scenario, but I will check it with our QC team next week and will update this topic once I have more information.
)