How to power on few VMs at the same time on recovery site during Recovery Plan execution?

[qwert1235]

Hello:

During SRM execution (failover) VMs on recovery site will start one by one, but not all at the same time. At that case, especially if you choose to change IP during failover and have many VMs, it will take for a while till all VMs will be powered on. If for example, you have 100 VMs and it takes 3 minutes per each VM you are looking to wait 5 hours till all VMs will be powered on (default timeout for network setting change on SRM is 10 minutes and the same for heartbeat).

Is here a way to spin up (power on) all VMs at the same time (to speed up the recovery process)? If it was design to power on VMs one by one in order not to overload VC/ESX, is there a way to power few VMs at once (let's say 5-10)?

I know this is the issue for SRM v1.0 and v4.x

Any help would be really appreciated

Thanks a lot!!!

[dcoz]

Hi high priority VMs will power one sequentially. This is by design.

The normal priority vms will power on in parellel if you have DRS and multiple ESX hosts within a cluster. I cant remember the value thats will power on in parallel, but you should be able to speed up your power on time by way of having multiple ESX hosts within the cluster andmost of your vms in the normal priority category.

The low priority VMs will also power on in parallel again if you have multiple ESX hosts.

Hope this helps

Dougie

[qwert1235]

Dougie,

It does help, thank you!

However, I am still looking for some option that will allow me to power on all high priority VMs at once.

And the same with normal priority VMs: power them on the cluster with few ESX hosts will increase speed in X times (where X number of ESX hosts I have in the cluster), but I want to be able power on all (or few) VMs at the same time.

Do you have any ideas, how it could be done?

Thanks,

[dcoz]

Hi,

Unfortunately you wont be able to power on all high priority VMs at once through the recovery plan.

I would advise you to keep the high priority VMs to a minimum due to the time it takes.

In terms of the normal to low priority see this post http://communities.vmware.com/message/1574316#1574316

The only thing you could do is reduce the time the recovery plan takes to wait for network, and vmware tools OS heartbeat. But this is a test and see how you go scenario.

Dougie

[qwert1235]

On my test environment I have only 1 ESX host on recovery site and when I am failover 4 test VMs (all of them normal priority) they will power on one by one (not 2-3 at once).

I wonder why I am having this issue… ESX host has a lot of resources...

Any ideas?

Thanks,

[pcerda]

Hi,

Have you tried with vApps? DRS only allow to start VMs one by one according to the priority of the VMs.

vApps allows to start several VMs at the same time, or one by one in the order you choose.

I don't know if this is possible in Site Recovery Manager, but you can try...




Regards / Saludos

-

---

Patricio Cerda !http://www.images.wisestamp.com/linkedin.png!

VMware VCP-410

Join to Virtualizacion en Español group in Likedin

See My Blog

See My Linkedin Profile

-

---

Si encuentras que esta o cualquier otra respuesta ha sido de utilidad, vótalas. Gracias.

If you find this or any other answer useful please consider awarding points by marking the answer helpful or correct. Thank you.

[mal_michael]

As far as I know, SRM is not aware of vApps.

I don't think DRS powers on VMs one by one. And since qwert1235 only has one host at the recovery site, I am quite sure that DRS is not enabled.

[mal_michael]

This is really strange behavior. In my environment VMs are powered on in pairs even if there is only one host at the recovery side.

[qwert1235]

Michael,

Thank you very much for your input.

Only one question: what version of SRM are you using? v.1.0.x or version 4.x?

I am using v 1.0.1 (yes, I know it's older version, but I have to use for some time )

Thanks

[mal_michael]

I have started with 4.0, upgraded it first to 4.0.1 and eventually to 4.0.2. VMs always behaved as expected.