vSphere 6.0 U1

[danswartz]

I hit this too - updated two hosts from 6.0 => 6.0u1 and suddenly replication jobs failing with authd ssl errors. Made this change per vmware:

in /etc/vmware/config
vmauthd.ssl.noSSLv3 = false

success!

[NerdyBarry]

We applied the hotfix and can now back up our ESXi 6 hosts. However, we noticed that vCenter tags are not visible through Veeam on our vCenter 6 instance. Is anyone else experiencing this issue? I'm not sure if it's related to the SSL bug or not.

[agiesen]

Curious, does disabling SSLv3 in Windows stop Veeam from attempting to use SSL?

[akrimmer]

Same issue here after updating to ESXi 6U1 last night. Re-enabling SSLv3 per the OP link fixed it.

[dahuafschmied]

in may 2015 i had a similar problem with ssl in debian 8 perhaps it is the same background:
http://forums.veeam.com/veeam-backup-re ... 29285.html

[wreedps]

When will the update be publicly available?

[Vitaliy S.]

When will the update be publicly available?

The hotfix for this problem is already available through our support team. If you're referring to Update 3 for Veeam B&R, then please review foggy's response in the beginning of the topic.

[wreedps]

I opened a case to get the temp patch.

[Vitaliy S.]

Curious, does disabling SSLv3 in Windows stop Veeam from attempting to use SSL?

Can you please clarify what setting in Windows sever you're referring to?

[lightsout]

You can tell IE not to use SSLv3 down the bottom of the advanced settings. I will say it didn't make any difference for me!

[Vitaliy S.]

Yes, that's correct. IE settings do not affect proxy/backups server and vCenter Server communication.

[danswartz]

Opening a new thread rather than hijacking the vsphere 6.0U1 thread (since I have no idea if there is a connection.) I have vsphere 6.0U1 on the host being replicated, and running veeam B&R 8.0.0.2030. I am noticing a major delay (on the order of minutes) when replicating VMs. Out of the dozen or so VMs on that VMFS datastore, 3 are replicated hourly (backups of all are done nightly). In all 3 cases, there is a major delay for the 'Processing Configuration' phase. On the order of minutes. Even more strangely, for the first two VMs, the delay is always the same (7:38 minutes and 10:09 minutes respectively). The 3rd VM's delay varies, but is also on the order of 7 minutes or longer. There are no error messages I can see in the vsphere/vcenter task information, and the replication job does finish with no errors. Note that the backup jobs do not have this issue (they do not have the 'Processing Configuration' phase. I can't swear as to when this started, but my vague feeling is when I upgraded the host to 6.0 (or maybe 6.0U1?) I you want me to open a ticket, I will do so, but I am more curious, since there doesn't appear to be any negative impact - just curious if anyone else has seen this?

[foggy]

Dan, I'd still recommend to open a case, since most likely logs contain information about what actually happens during those delays.

[danswartz]

Opened case ID #01062626. I renamed today's logfile for that job, then re-ran it. This was it is 1/10th the size...

[danswartz]

Working now (thanks Support!) In my post in the 6.0u1 thread, I mentioned hitting the sslv3 issue and applying the vmware workaround, but that was to address replication not working at all, so I only applied it on the production host. The backup host is where the replicas go, so it was hitting the same issue (not sure why the jobs would eventually work - I guess the sslv3 thing is not fatal there?) Anyway, per Support, I applied the same vmware workaround to the backup host, and now the configuration fetching phase completes in a matter of seconds.

[dan11]

After updating to esxi 6.0u1 and implementing the hotfix for SSLv3 problem, erverything works fine.

Just one problem with Surebackup: The VMs don't identify the network connection as "Domain Network". Surebackup completes sucessfull but exchange services for example are unable to start (because of identifying the connection as public network). This happens with the DC too.

Does anyone facing the same problems after updating vmware to 6.0u1?

[lightsout]

I've not had that problem after applying the patch.

The only issue I see is, depending on how you configured your SureBackup network, can you confirm that Veeam's virtual appliance is on the same ESXi host where the SureBackup network is defined? e.g. if SureBackup uses a standard switch then it is typically locked to one host.

[foggy]

I believe this is not specific to this update. Windows Firewall recognizes the virtual lab network as a new one and applies "public" firewall profile to it.

[dan11]

Yes, all VMs in the Virtual Lab are on the same host. The Virtual Lab Network is connected, ping is running...
this never happened since I'm using Surebackup for 2 years...

[foggy]

Please try this workaround.

[dan11]

Thanks foggy, it works now. I didn't run in to this problem till now because I never changed the Virtual lab proxy after updating Veeam… I did recreate the Virtual Lab after the vmware migration...

[foggy]

That explains. Btw, the fix for this issue will be included in the upcoming Update 3.

[Gostev]

Hi everyone! v8 Update 3 that (particularly) fixes the issue that started this topic went gold yesterday. If you'd like to participate in the pilot, please contact our support for the download link. Thanks!

[jamerson]

are there reasons why is the link not public yet ? and need to access it just through the support team ?

[Gostev]

Because it is not generally available yet. We always start from a week or two of pilot deployments.

[simwood]

Thanks for this! Solved my problem after hours of chasing around VSAN issues that weren't there.

[jamerson]

Thank you
already contacted the support team.

[lightsout]

There is now a patch for 6.0 U1 which fixes the NETDEV WATCHDOG issue too.

http://kb.vmware.com/selfservice/micros ... Id=2132153

[chris.childerhose]

Sweet I was waiting for this before upgrading my hosts from 5.5. Now I can move forward!!

[Gostev]

B&R 8.0 Update 3 bringing full support for vSphere 6.0 Update 1 (without having to enable SSL on hosts) is now generally available > KB2068