V9 Snapshot Problem

[stmux]

Updated from v8 to v9 to test and determine whether v9 is ready for production and it does not appear to be.

The first backup is a Windows vm with a 80GB hard disk. v8 would do a full backup in around 25 minutes and the snapshot was removed in between 1 and 2 minutes. v9 took 26 minutes to back up the files at 50 MB/s and the snapshot took 1hour and 15 minutes to be removed. Anyone else seeing this behavior? Anything I should be looking for as what could be causing this?
Thanks,
mux

[Shestakov]

Hello,
What vSphere version are you at?
Thanks!

[stmux]

This test is with version 5.5 with latest updates.

FYI, I just did another test with our mail server vm which also has an 80GB virtual hard disk. 16GB were read in 11 minutes 30 seconds and the snapshot removal took over an hour. Something is obviously not working right. Is there a new setting that may be on by default that could have something to do with this?
Thanks,
mux

[alanbolte]

Quickly double check that this is actually specific to v9:
If you create a remove a snapshot manually via the vSphere client (with 10-20 minutes in between creation and removal) how long does it take to remove the snapshot?
Are there any snapshots on the VMs you tested when the job is not running, or are they in Consolidation Needed status?
Is snapshot removal by Veeam actually showing as taking an hour in the vSphere tasks and events, or just in the Veeam GUI?

[tsightler]

Pretty hard to understand this behavior and I've not seen this on any of the v9 installs I've worked with or heard this from any other customer. Not only that, but Veeam itself doesn't control the snapshot removal, it's just telling VMware to do it. Not saying it's not some issue, just having a very difficult time understanding what it could possibly be. Probably best to open a support case and have them take a look.

[stmux]

I noticed that all of our jobs created in v8 are showing (Different Subnet) in the job action window. So, what I did is create a new job for the same server showing the problem. This time the job showed (Same Subnet). The snapshot removal took 2 minutes and 32 seconds. I am going to create all new jobs and hopefully this will no longer be an issue.
Thanks for the feedback,
mux

[Shestakov]

I would also suggest contacting technical support to find out why snapshot removal takes so much time, regardless you can recreate all the jobs.
Once you do, please provide the case number here. Thanks!

[foggy]

I noticed that all of our jobs created in v8 are showing (Different Subnet) in the job action window. So, what I did is create a new job for the same server showing the problem. This time the job showed (Same Subnet).

This comes down to the guest interaction proxy selection, which was served by the backup server itself after the upgrade, while once you've re-created the jobs, automatic selection algorithm came into play. Not sure how this correlates with snapshot commit time, though.