#Veeam Error “failed to open VDDK” and cached credentials

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

I was configuring a windows server for Veeam Backup & Replication 6 at a customer, and after some days of work I got a weird error while running some new backup jobs just created:

Error: Client error: Failed to open VDDK disk [[XXXXXX] VMNAME/VMNAME.vmdk] ( is read-only mode - [true] ) Failed to open VMDK. Logon attempt with parameters [VC/ESX: [];Port: 443;Login: [****];VMX Spec: [moref=vm-116];Snapshot mor: [snapshot-161];Transports: [hotadd]] failed because of the following errors:

Trying to run some of those failing jobs manually, I saw the job was stuck while trying to copy the vmdk disk file for about 20 minutes, without any single byte transferred. Those timeouts made me loose almost two hours of tests, but at the end I managed to find out the problem.

The strange thing was to have several jobs, all configured in the past days, going on running smoothly. Since Veeam Backup is a windows-based software, my guesses went straight to the credentials used to run the backups. As a temporary step, I had configured the Veeam services to run with domain administrator credentials; asking to customer, he had changed the administrator password in the previous days.

As always on microsoft systems, cached credentials from previous service start (using the old password) were still authenticated by vCenter, thus allowing Veeam backups to run. The misleading situation was the new jobs would have been eventually run by Veeam using those same old credentials, but that was not happening for whatever reason.
At the end, the solution was:
– to complete Veeam deploy as designed, so creating a “veeam” account specifically to run Veeam services and do VSS logins on windows virtual machines. This user has a complex password without expiration. In this way, customer can change the administrator password whenever he wants without compromising Veeam
– a reboot of the windows server where Veeam was installed cleaned all the cached credentials. Needless to say, after the reboot all jobs finished successfully.