[vCloud] Jobs need multiple phases

[b.vanhaastrecht]

Our setup:
4 ESXi 5.1, datastore's on HP Lefthand (iSCSI)
vCloud 5.1.2, backup sources are customer vDC's
Veeam backup server is a VM which also has iSCSI access to the LUN's. (So primary is proxy backup, secondary hotbackup, and third netbackup.)
Veeam backup server has no network access to the customers vDC's
Administrator account used for backup of VM's, guest indexing and application indexing
Veeam 7.0 Patch1

We have multiple backup Jobs to backup the customer vCloud vDC's. Some Jobs need multiple backup passes to run successfully. I notice two things:
1) The job log states in runs that fail the hot backup method is used, whyle in succesfull phases the proxy is used
2) The job log states the administrative share could not be reached. This is true as there is no network levelaccess between the Veeam server and the customer vDCs. To my knowledge the API of the VMware tools is used to access the quest OS and run the guest indexing agent.

Failed runs:
7-11-2013 21:01:52 :: Failed to prepare guest for hot backup. Error: Failed to connect to guest agent. Errors:
'Cannot connect to the host's administrative share. Host: [172.17.10.10]. Account: [].
Win32 error:The network path was not found.
Code: 53

Succesfull runs, same job:
(No errors regarding guest indexing)
6-11-2013 21:27:07 :: Using backup proxy VMware Backup Proxy for retrieving disk Hard disk 1 data from storage snapshot

The same job go's in retry, and sometimes it needs multiple runs before it runs succesfully. Then the job log states:
1) It has used the proxy, SAN based backup. How come the failed runs go in hotbackup? Is this a error log bug?
2) Howcome in next runs the error regaring accessing the guest OS is no longer there? The credentials are the same, nothing hapend with the VM at this time period.

Can anybody explain why my job's needs multiple runs while nothing acutualy changes in setup during all backup phases.

[veremin]

Hi, Bastiaan.

Kindly please avoid posting log snippets, since it’s against our forum rules. Also, be aware that the team behind this community is not able to help you with debug logs research. Have you opened a support ticket on this issue, as requested when you click New Topic?

1) It has used the proxy, SAN based backup. How come the failed runs go in hotbackup? Is this a error log bug?

Seems like something was wrong with Direct SAN at the time of backup, so the VB&R decided to switch to the second preferable proxy mode.

2) The job log states the administrative share could not be reached. This is true as there is no network levelaccess between the Veeam server and the customer vDCs. To my knowledge the API of the VMware tools is used to access the quest OS and run the guest indexing agent.

Yep, you're right. Whenever the network mode fails for some reason, VB&R should use network-less mode in order to connect to VM administrative share. You'd better open a ticket with our support team and let them investigate this sporadic environmental issue directly.

You can also try to reverse the sequence of application-aware processing, using InverseVssProtocolOrder (DWORD) registry key, and see whether it makes any difference. With this key, jobs will always try network-less processing (VIX) mode before network.

Thanks.

[b.vanhaastrecht]

I cannot open a support ticket as there is a problem with the ticket system. We have a hosted license, and when I select this product for support the drop-down menu for version stays NONE. So therefore I created my cummunicty question first, and then I get in contact with Veeam to get the issue fixed on their website.

I will look at the InverseVssProtocolOrder (DWORD) registry key. And I will contact support to raise a ticket by phone.

[b.vanhaastrecht]

Ticket nr: 00475261

[veremin]

Thanks for updating the topic with the support ticket number. Let’s wait and see what support team says about this issue.