So after updating my vSphere 6 home lab to Update 1 I noticed that when I woke this morning that all my Veeam jobs had failed over night…bugger.
After digging around in the logs (C:ProgramDataVeeamBackup) I discovered the following errors.
I then did a bit of searching on the internet and found the following VMware KB and Veeam Post
So I edited the /etc/vmware/config file with WinSCP and added in the vmauthd.ssl.noSSLv3 = false at the end of the file.
I then restarted the rhttpproxy service by enabling SSH on the host and using putty to run the following command
/etc/init.d/rhttpproxy restart
Once the service has been restarted I repeated this on the remaining on hosts in the cluster, I was then able to successfully re-run the Veeam jobs.
So to summarise Gostev on the Veeam forums posted saying the following on Monday.
“As far as the original issue that created this topic, the research has now been completed.
SSL usage seems to be isolated to NFC API, and is caused by a bug in parsing the list of supported SSL/TLS protocol versions on our side. Despite TLS was added at some point, this bug went unnoticed, as things continued to work normally over SSL – until now.
The good news is that this will be very easy for us to fix – so, we are planning to provide the hotfix for v8 Update 2 soon, and also include this fix into v8 Update 3 scheduled to be released late September (with the main feature being Windows 10 support). Thanks”
It’s good to see Veeam reacting so quickly to this as it appears to have even caught VMware themselves off guard as it also affected View Composer connectivity as per the above VMware KB.
Veeam also have released their own KB it can be found here
vWud.net 