V2V and backup/replication jobs
We have to v2v one of the largest machines. From what i have seen with veeam 8 is that if the vmware id changes, the machine is seen as new machine.
How to prevent this?
How to prevent this?
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: V2V and backup/replication jobs
There's currently no way to avoid this, besides editing Veeam database to match the IDs, which we do not recommend to do without support assistance.
Re: V2V and backup/replication jobs
We have full support so one phonecall/rss would solve this?
-
- Chief Product Officer
- Posts: 31816
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V2V and backup/replication jobs
If you actually V2V the machine, you have to start backing it up from scratch as the new machine, instead of attempting to match the ID (even with a help of support). Matching can only be done when the only thing that changes about a VM is moRef ID (but actual VM remains exactly the same). Thanks.
Re: V2V and backup/replication jobs
V2V is still the same machine, a few thinks change that is true. The only reson is because someone had thin disks in mind while it has to be thick.
So essentially the machine stays the same and the old one isn't comming back, only the disk will be thick and not thin. But even then it is a new machine for veeam?
So essentially the machine stays the same and the old one isn't comming back, only the disk will be thick and not thin. But even then it is a new machine for veeam?
Re: V2V and backup/replication jobs
What would be the best way to update the target after the v2v?
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 times
- Joined: Jul 26, 2009 3:39 pm
- Full Name: Luca Dell'Oca
- Location: Varese, Italy
- Contact:
Re: V2V and backup/replication jobs
Yes, we refer to VMware MorefID to identify VMs, it's the only stable and guaranteed method.
Even if the VM will be marked as a new one, most of the blocks of the VM itself will be inside the existing job, so I'm expecting anyway a new run of the backup to deduplicate a lot thanks to existing blocks. Maybe you can simply let the job run and see if the deduplication ratios will be good anyway...
Also, honestly I don't see thin/thick disks to affect block changes to be honest.
Even if the VM will be marked as a new one, most of the blocks of the VM itself will be inside the existing job, so I'm expecting anyway a new run of the backup to deduplicate a lot thanks to existing blocks. Maybe you can simply let the job run and see if the deduplication ratios will be good anyway...
Also, honestly I don't see thin/thick disks to affect block changes to be honest.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Re: V2V and backup/replication jobs
Well, done the big step this year. It took Veeam just 2 and a half days to replicate the V2V machine using all bandwith available during those days. In my humble knowledge, that's a full replication job without the use of any of the off-site dedupe blocks. The whole machine should have been in the cache (see my post about wan accelerator cache usage) sinds the V2V machine is exactly the same as the original.
Don't know if that is working as designed or not.
Don't know if that is working as designed or not.
Who is online
Users browsing this forum: No registered users and 29 guests