- Service Provider
- Posts: 145
- Liked: 10 times
- Joined: Jun 29, 2013 12:14 pm
- Full Name: Peter Enoch
After seeing this message from the log after on of our Prod. VMware VM's was changed in disk seize I start looking at this in the forum and can see this is a known VMware issue and not Veeam.
I still think that some of the suggesting of some how of handling this in Veeam would be nice. Some of the option as other wrote could be: Fail the replication of that VM, Delete all snapshots (as it is now) or replicate as new VM so you still have the "old" VM with it's snapshots. When max snapshot in the replication job exceeds the new replicated VM vs. the old then delete the old replicated VM.
Is this VMware only or is it the same story with Hyper-V?
What if we reseize the VMware VM, then make a backup in Veeam and then replicate with the source set to Backup Repository instead of directly, will this also delete all the snapshot on the destination?
- Product Manager
- Posts: 23182
- Liked: 1602 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
For VMware this happens, because a new restore point (snapshot) can no longer be mapped to the source disk, since it doesn't match the source any more. For Hyper-V, please see this topic for more info > Resize vhdxenoch wrote:Is this VMware only or is it the same story with Hyper-V?
Yes, because snapshot should always "match the size" of the source virtual disk, otherwise there might be issues with snapshot commit operation.enoch wrote:What if we reseize the VMware VM, then make a backup in Veeam and then replicate with the source set to Backup Repository instead of directly, will this also delete all the snapshot on the destination?
Users browsing this forum: No registered users and 20 guests