Hello,
we are implementing several replication jobs on 4 separate Veeam B&R servers, each job having LUNs as source containers.
If the jobs run at least one time and thus replicas have been performed and "VM_replica" registered in vCenter, it's not clear to me what happens whenever a VMware admin performs a storage vmotion of a VM from a LUN which is source for a given job, to a LUN which is source of another job; do the VM replications fail both for original job and for destination job? If so, what's the best way to avoid this behavior other than implement a "change management" procedure stating that every storage vmotion must undergo a Veeam admin evaluation?
Thanks.
-
- Influencer
- Posts: 12
- Liked: 1 time
- Joined: Apr 15, 2011 1:26 pm
-
- VP, Product Management
- Posts: 27371
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: LUN-based replication jobs and storage vmotion
Hello Enrico,
I believe the only job that will fail is the second one, since it will try to re-register VM with the same name, which is obviously not possible. To avoid that you can use VM folders or other containers as source for your replication jobs.
Thank you.
I believe the only job that will fail is the second one, since it will try to re-register VM with the same name, which is obviously not possible. To avoid that you can use VM folders or other containers as source for your replication jobs.
Thank you.
-
- Influencer
- Posts: 12
- Liked: 1 time
- Joined: Apr 15, 2011 1:26 pm
Re: LUN-based replication jobs and storage vmotion
Hi Vitaliy,
thank you for the answer, we chose to set the jobs LUN-based mostly in an effort to eliminate the chance to have more than one snapshot active on the same source LUN at the same time, it is of paramount importance for the customer to avoid disservices caused by loss of performance or worse, lack of lun space (this has already happened).
In my first post scenario, what will be the best way to handle the replication error after it has occurred, while preserving the pre-existing replica? (my guess: unregister the old replica, move the replica files from the first job target LUN to the second job target LUN and re-register it...)
Thank you,
Enrico
thank you for the answer, we chose to set the jobs LUN-based mostly in an effort to eliminate the chance to have more than one snapshot active on the same source LUN at the same time, it is of paramount importance for the customer to avoid disservices caused by loss of performance or worse, lack of lun space (this has already happened).
In my first post scenario, what will be the best way to handle the replication error after it has occurred, while preserving the pre-existing replica? (my guess: unregister the old replica, move the replica files from the first job target LUN to the second job target LUN and re-register it...)
Thank you,
Enrico
-
- VP, Product Management
- Posts: 27371
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: LUN-based replication jobs and storage vmotion
Enrico,
That would work but in version 6 only, as replica mapping into existing VMs is going to be introduced in the next release. Currently you cannot re-use replicated files from another job, in other words if you move one VM to another job, this job will run a full pass for this VM, as moving VMs between the jobs is not possible.
Thanks.
That would work but in version 6 only, as replica mapping into existing VMs is going to be introduced in the next release. Currently you cannot re-use replicated files from another job, in other words if you move one VM to another job, this job will run a full pass for this VM, as moving VMs between the jobs is not possible.
Thanks.
Who is online
Users browsing this forum: Baidu [Spider], Majestic-12 [Bot] and 106 guests