Veeam CDP error

Have you got any hosts offline or in maintenance mode? What version of ESXi are they running?

The ESXi version is 7.0.3 and the we got no hosts running offline or maintenance mode

Check if necessary ports are open: 

https://helpcenter.veeam.com/docs/backup/vsphere/used_ports.html?ver=110#cdp-components

And when I remember correctly, DNS is mandatory for CDP filter driver installation:

https://forums.veeam.com/vmware-vsphere-f24/v11-install-cdp-t72139.html

I had this on the weekend. DNS was the issue, I could not figure out when my problem was and ran out of time in the lab so in the end I just did host file entries to get it working. 

Considering that the screenshot shows an IP address, looks like @Geoff Burke & @vNote42 are into the right answer here talking DNS.

Yes, problem is stick to DNS

https://forums.veeam.com/post427252.html?sid=d4cba4506cf3c2799da1401a9a49ac8e#p427252

I agree with you and @Geoff Burke. All vital guides shared by you all point to DNS. I hope these tip(s) will be enough to help resolve his issue.

DNS is needed as noted with CDP. When I tested it in my lab for my book chapter I had the same issues until I addressed DNS then it worked no problem.

Hi team , i have a little question.

I try configure CDP in a veeam v12 (last patch), but my server is without domain ( i’m following de the “best practices”) so, i think that i need configure the “hosts” file to get the correct dns of my vcenter.

But i still with the failure, someone know if i can use the “hosts file” for correct the failure?

or

¿Someone knows wich is the correct configuration for this file?

If you need to do hostnames use the hosts file to do it. Easiest way around it without domain.

It was also DNS for me, but I will explain why and how I resolved it without editing hosts file.

First some background on my home lab setup:

vSphere 8u2 (evaluation)

VBR 12.1

2x Intel NUC 13th Gen w/ ESXi baremetal

VMware Workstation Pro 17.5 (Windows Desktop)

VCSA8 (VM inside Workstation)
1x Windows DNS server (VM in Workstation) with manual A and PTR records

Of course, I thought, no way it is DNS 😈, all of my backup and replication jobs are working fine! I had no issue adding all the components to my VBR server. I can see all the VMs and datastores in Inventory. I can ping and nslookup from VBR and DNS (Windows) to all the VMware infrastructure and back. All the IP/FQDNs are resolving fine!

EXCEPT, when I double-checked nslookup from the vCenter, (after enabling SSH and shell, with PuTTY and root credentials) vCenter was resolving IP/FQDN to the VBR fine but NOT resolving the VBR short name.

example:

nslookup vbr01.mydomain.local = returned the correct IP

nslookup IP_address_of_vbr01 = returned correct FQDN

nslookup vbr01 = failed to find server

I considered adding another DNS entry for short names or editing the hosts file on vCenter, but those seem messy and vi editor doesn’t like me 😀. That must be why I didn’t have any luck trying to edit ‘/etc/resolv.conf’. I decided to check my vCenter DNS settings again, since I am not using a domain controller.

My issue was mostly with the VCSA Direct Console UI (DCUI). I could not save a Custom DNS Suffix in the GUI, it would always fail. However, using the CLI utility, I was able to add a Custom DNS Suffix for my lab domain and then nslookup to the short names was working!

user swint commented:

SSH to the vCenter as root, type "shell" to get to the bash shell, then run the following cli tool.

/opt/vmware/share/vami/vami_config_net

Installing I/O filters failed again, BUT this time for a different error! Progress!

Veeam already had a KB for that issue with vSphere Lifecycle Manager
https://www.veeam.com/kb4096

After remediating all the hosts, I/O Filters were installed and I ran my first CDP Replication policy with SUCCESS!🤑

Great to hear @DerekDavis that you fixed the issue and nice to see the steps for others to follow.  😎

@DerekDavis - thank you for the hint.

Exact Virtual Lab scenario. Resolving with FQDN worked on VCENTER, ESXI, VBR, so I also thought that it couldn’t be DNS. Then SSH to vcenter and pinging to short hostname, bang, exactly :) thanks again.

I’ve found that it’s almost always DNS :) If not, remediation of the hosts was missed in a few cases.