Full Performance After Storage VMotion

[pendragoncrw]

Hi all,

Seems like this is not my week for Veeam (which is unusual since I hardly ever have problems with it) across 15-20 sites.

Here's the chain of events:
1. On 30 VM's, run defrag and sdelete to zero out free space.
2. Run full backup. Performance is very good. As soon as it hits the white space, the processing rate screams (as I expect it too). Everything is running in VA-hotadd mode. Bottle neck is source 57%, proxy 29%, network 41%, target 58%
3. Need to storage vmotion a whole bunch of VM's around to cope with some space allocation. Eventually all VM's are put back on their original datastores.
4. After storage vmotioning is complete, I run the defrag and sdelete again to zero out the free space.
5. Make a new job, re-add all the VM's, same settings as my original job and the performance is atrocious. It hangs around 25mb/s the whole way through the job, even when it hits the white space.

I've verified it's not falling back to network mode, I've re-run my defrag/sdelete script on allt the VM's, re-booted the Veeam server, bounced the hosts, and the performance is still in the gutter. It lists the bottleneck as source 99%.

I am very perplexed, especially since the speed does not increase at all when it hits the white space.

Any thoughts?

Thanks,
Chris

[pendragoncrw]

Minor Update: The behavior is not consistent across all VM's. VM's that were not storage vmotioned appear to be okay, some that were storage vmotioned are stuck at the lower processing speed, some that were storage vmotioned are okay. I guess we'll have to see how it goes for our next full.

Chris

[Gostev]

Hi, actually averaged bottleneck across all VMs won't tell you anything if you are having issues with only certain VMs. Instead, check out the instant bottleneck stats when affected VM disks are processed (hover over the Bottleneck label in the real-time stats windows with the mouse).

On a side note, CBT during full backup (when processing screams through "white" areas) does not work reliably with VMware, so you should not expect it to work for every VM in all cases. There is a separate topic here discussing this (it can be fixed individually for each VM, but too much work and so does not really worth doing). When this does not work, it is expected that the job will read every block of the processed VM to determine its content.

Thanks!