Veeam Quick Migration

[Louharle]

Hello, I Have an environment with roughly 70 VM's that I am migrating to a new cluster with new hardware. Rather than take the efforts to do temporary fibre channel zoning between the old and new environment I am considering using quick migration to do this. My question is this: I understand that either a suspend or power off needs to occur to commit the final changes/snapshot at the end - can this be scheduled / set to be done manually or does it just automatically happen after the migration completes? Many of these servers are sizable AND cannot go down during the day....

Thanks in advance,

[Vitaliy S.]

Hello Louis,

Actually it depends on what VMware license you have. If you have storage vMotion licensed then you can migrate a live VM with no downtime. If you don't have this feature licensed, then this switch will happen with a suspend/stop operation. In order to control it, you can use replication jobs and then trigger a permanent failover using Veeam backup console at the off hours with no impact to the users.

Let me know if that helps!

[veremin]

As to using replication jobs as migration means, we have an existing discussion regarding it; might be worth reviewing. Thanks.

[Louharle]

Thanks to both of you, Storage vMotion would necessitate me adding the existing fibre fabric to the new environment, which I would like to avoid. I will investigate the replication thread and see what it offers. Thanks again!

[Louharle]

In reading the article mentioned about using permanent fail-over it mentions this: " but that appears to commit the delta of the target. Is it possible to commit a delta of the source?" - is this something I should be concerned about? I was under the impression that it committed all the change from the source to the target, is that not true? When I do a permanent fail-over does it ask to shut down the source? Any info is greatly appreciated.

[foggy]

Failover assumes your source VM is already turned off (typically it is used in a DR situation). So, as mentioned, to avoid data loss, it is recommended to shut the source VM down first, perform final replication of the latest changes, and then failover to the replica VM.