One Proxy slow to start reading data

[mpoublon]

I've opened a ticket (5188391) on this but also wanted to check if anyone else is having this issue. Our primary Veeam server also has the backup proxy installed and when backing up a virtual machine starts reading the hard disks (vmdk files) within a minute or so of starting the job. Our secondary backup proxy takes upwards of 10-20 minutes to start reading data from the hard disks using CBT. Both servers are similarly configured (OS, RAM, Direct attached to the SAN, etc) but are not identical hardware. DNS and connectivity to everything seems to be fine as the job eventually starts moving data around. We've rebooted the server with the issue as well as our virtualcenter server and have not had any luck resolving this.

[Gostev]

I would look at the job and data mover agent logs to see what operation is taking 10-20 minutes.

[mpoublon]

For comparrison, a similar section of a log on our other proxy server takes 21 seconds (instead of the 11 minutes) to move on and work on the data.

[Gostev]

Please do not post log snippets on forum, as requested when you click New Topic. If you need help making sense of debug logs, please continue working with our support.

[mpoublon]

Sorry about posting the log snippet, must have missed that note.

The relevant info is that on one proxy server (the functional one) the section of the log file takes 21 seconds, while the other takes many minutes (11 minutes in the log I was looking at - sometimes longer). Whatever step that happens between parsing the text config files for the VM and the SAN path selection and actual reading of data seems to have a hangup on one of my proxies.

The only change to both of the proxies recently was to move from dedicated Fibre Channel HBA's over to a converged network adapter. Both systems have matching drivers/support software for the new hardware. Direct SAN access works fine once the process metioned above finishes.

[Gostev]

I believe that VDDK is establishing the connection with vCenter during that period. And that is something done directly from proxy server to vCenter, so this is where different proxy servers may potentially have different results... let's see if our support analysts can figure out the problem for logs.