check if you have permission in all cluster, or only in one host.
You credential need be administrator of all cluster,
I've made the given username the "Administrator" Role on Datacentre & cluster level.
If I check on the ESX servers, in the permission tab is the role made available to both servers.
The pop-up keeps comming back and asking me for the credentials. The frustrating thing about it is it isn't give me any errors.
Or should I reboot VC or ESX to apply these permission settings?
Rebooted everything, each ESX server and the vCenter server. But I still can't connect.
Does anybody have any ideas?
Have you been able to login with this user before? VDR needs to have a direct admin login, and currently does not support customer permissions.
The credentials asked in the screenshot are the same as the Administrator credentials for vCenter. And it's a 'domain administrator' in our Active Directory.
So it's asking fot it's password, but it keeps coming back.
I am making progress on it
I made the biggest mistake to put the VMDR in management LAN. Now I changed it to production LAN for credential check on an domain controller. If I click connect it is asking for the credentials again, after that it's doing nothing
Status : Not connected
I am experiencing the very same problem with my VMware Data Recovery instance. My VMDR and my vCenter are both VMs on the same cluster. I have tried with both my own Admin-privileged account as well as with the 'true' Administrator account on the server. The vSphere client is running on the desktop of the vCenter itself. I have found failed logins in the vCenter Windows 2008 event logs, that say "Bad user name or password", which seems strange, as I'm quite sure I've typed in the correct passwords. Starting to wonder if perhaps the VMDR plugin is mangling my password before sending it?
In any event, quite interested to see this resolved, as we aren't able to access our backups.
Edit: Just confirmed that the Audit Failure for the attempted log in from VMDR in the Windows Security Log is labeling the failure as a bad password:
Failure Reason: Unknown user name or bad password.
Sub Status: 0xc000006a
According to MS, this Sub Status means "bad password".
I even temporarily changed my password to a short, low-complexity variant to see if that was the problem, but no change.
I ain't getting 'bad password' or 'bad credentials' errors anymore. Just because of my VMDR virtual machine wasn't able to talk with the Active Directory in my case. So it wasn't able to check the credentials.
So I'm getting 'Succes audit' only. But still it remains unconnected..
Still don't have a clue how to get VMware Data Recovery working. What can we / I try?
1 person found this helpful
Alright, so I fixed my problem. Here's what I did. This solution assumes basic Linux/CentOS skills.
First, open a unix console to your VMDR machine, and create the following file:
The file should have just the following line:
Save the file.
Now, stop VMDR service with:
service datarecovery stop
Then, start VMDR service manually, now in verbose mode:
Assuming a few screens of input, and the service doesn't crash (you shouldn't be returned to command prompt yet, if that happens, you have other problems out of the scope of this solution), go into the vSphere client, and attempt to connect to VMDR via the VMDR plugin. Keep an eye on the console window of the VMDR while you are doing this, and attempt to authenticate. You should see the VMDR attempt to connect to a particular IP address with the username that you specified in your authentication attempt, and it may fail.
What I saw, which first alerted me to a misconfiguration, was that my VMDR was trying to communicate back to an IP address of my vCenter that was not accessible from the network of the VMDR machine. This was happening because when I logged into the vSphere client, I used the vCenter host name, rather than an IP address on the network that VMDR lives. (My vCenter has two interfaces, one on my Management network, where VMDR lives, and one on a development network.)
Solution: When you use vSphere client to connect to the vCenter, make sure you specify the IP address of the vCenter server that your VMDR will be able to communicate to, for the vSphere client passes that IP address to VMDR when it trys to authenticate the first time.
When you are done troubleshooting, press CTL-c in the VMDR console, remember to delete the datarecovery.ini file, then either reboot the VMDR or try service datarecovery start, then logout.
Hope that helps! If nothing else, you now know how to troubleshoot VMDR problems!
Well, I got it worked too.
In my case my problems had to do with my network. So I edited the hosts file in the VDR appliance, rebooted the thing and it's up and now I was able to connect immediately.
Thanks for all the tips! And for sharing your ini file creation / solution !
Thanks for the solution to find the problem.
I had a vcenter in three networks, esx in all the three networks and datarecovery in one of them. The ESX was added to vcenter via name, not IP-Address.
Adding the correct entries fpr vcenter and ESX in the /etc/hosts on DataRecovery made no change.
Had to change the hosts-file on my workstation and on the vcenter-server to get Datarecovery to connect.
So I wonderd who tells the DataRecovery what to connect to. Seems like:
1) vSphere Client tells DataRecovery to first connect to the host/vCenter name or IP-Adress which was given in the connection-dialogue of vSphere Client
2) I suggest vSphere Client (in case there is the DataRecovery-Plugin running) tells the DataRecovery-Service to connect to the hosts in vCenter, but if added via name to vCenter, the workstation which is running vSphere Client resolves the names and tells DataRecovery the resolved IP-Addresses.
So if you have the workstation in another subnet than DataRecovery and ESX connected to both subnets, you have to be sure your workstation resolves the hostname of the ESX to the IP-Address, that can be reached by DataRecovery.
Hope you understand me
magic, this worked perfectly for me and my multihomed vCenter, thank you!!
I had an idea the VDR was trying the wrong IP address but couldn't figure out how to get it to connect to the one I wanted, I thought changing the vCenter Server Managed IP would be enough, but sadly not.
Your idea of getting the vSphere Client to connect to the vCenter IP address that the VDR appliance could get to was what I needed, thanks!