When I tried to backup the virtual machine up using the “VMware VDP”, I receive this error:
“VDP: Backup job failed to backup client. Execution error: E10055:Failed to attach disk.”
Most of solutions I found on the web were dealing with something regarding the UUID virtual disk parameter and the “Windows 2008 R2” or “Windows Server 2012”. This is described in the following VMware KB. Fine, but I was trying to back up a Linux box???
Of course, I did try to back up the W2008R2 and after failing, I did change the parameter stated in the KB article. Guess what? No luck.
Then I opened the log file associated with the backup job. This log file can be found on the VDP appliance in the folder /usr/local/avamarclient/var-proxy-?/, where the “?” is the number such as one, two, … The log file name is something like “Server1 Backup-1376922623788-da863a8a6a1980efbcd9611275cd223ece51bf02-1016-vmimagel.log”. The log file stated:
2013-08-20 11:08:04 avvcbimage Info <16041>: VDDK:NBD_ClientOpen: attempting to create connection to vpxa-nfcssl://[OF_iSCSI_36GB] Web Server L/Web Server L.email@example.com:902
2013-08-20 11:08:25 avvcbimage Info <16041>: VDDK:CnxOpenTCPSocket: Cannot connect to server e1.popravak.local:902: Connection timed out
2013-08-20 11:08:25 avvcbimage Info <16041>: VDDK:CnxAuthdConnect: Returning false because CnxAuthdConnectTCP failed
2013-08-20 11:08:25 avvcbimage Info <16041>: VDDK:CnxConnectAuthd: Returning false because CnxAuthdConnect failed
2013-08-20 11:08:25 avvcbimage Info <16041>: VDDK:Cnx_Connect: Returning false because CnxConnectAuthd failed
2013-08-20 11:08:25 avvcbimage Info <16041>: VDDK:Cnx_Connect: Error message: Failed to connect to server e1.popravak.local:902
2013-08-20 11:08:25 avvcbimage Warning <16041>: VDDK:[NFC ERROR] NfcNewAuthdConnectionEx: Failed to connect to peer. Error: Failed to connect to server e1.popravak.local:902
2013-08-20 11:08:25 avvcbimage Info <16041>: VDDK:NBD_ClientOpen: Couldn’t connect to e1.popravak.local:902 Failed to connect to server e1.popravak.local:902
A-ha! This seems not having anything to do with the VDP or virtual disk parameters, but rather is a pure communication issue. I’m not sure how many of you guys have a firewall protecting the virtual infrastructure, but in my lab this is exactly the case. I have an ASA box between the VDP and the rest of the network, including management addresses of my ESXi hosts. From the log is apparent that the VDP needs a communication channel opened from itself to ESXi hosts’ management interfaces. This communication is sourced from the IP address of the VDP and some high random TCP port, to the ESXi management address and port TCP/902. After opening this port like this:
access-list VMWARE_IN extended permit tcp host 10.1.110.4 object-group ESXi-HOSTS eq 902
the backup was successful. The 10.1.110.4 is the IP address of the VDP and the ESXi-HOSTS is the object group containing all ESXi hosts’ management addresses.
It may be unusual to have a firewall somewhere between the VDP and the rest of the virtual infrastructure (ESXi host management address in this case), but the error reported in VDP (or dare I say the solution) is certainly misleading!
Thanks for reading.