I keep running into this one error trying to set up Data Recovery. I have it installed and the appliance imported. I go into the Solutions and Applications section and the VMware Data Recovery screen. I put in the IP of the appliance and click connect. It asks me for the password for the vSphere server and while that prompt is up, it shows an "Authentication failed" error. Once I enter that password, every time I click connect for the rest of my vSphere session, I'll get this error:
Error: Could not log onto the server. The connect attempt timed out. Please make sure that the Data Recovery Appliance is turned on
It is, of course turned on and I can go to the web interface, log in and click around fine. Not sure what I could be missing. Is there a specific port it's trying to connect on that I could test out? I'm at a loss as to why it would break at this point.
-Daniel
I attended a Webex today on Data Recovery and led the instructor to this forum topic and he said he'd have a look so fingers crossed.
When connecting to Data Recovery appliance the first time, the UI plugin sends the vCenter server IP address and credentails to the appliance so that it can authenticate whether the user is authorized to manage the appliance. There are a few cases where the the UI plugin ends up providing an invalid IP address to the appliance and hence the appliance cannot connect to the vCenter server to authenticate the connection. If vSphere client is running on the same machine as vCenter server and vSphere client logs into vCenter server using "localhost" or local IP address "127.0.0.1", the UI plugin send the local IP address to the appliance as vCenter IP address and hence the authentication fails. Also, in this setup, if vSphere client logs into the vCenter server using its machine name and IPv6 is enabled on this machine, when the UI client tries to resolve the machine name to IP address, it gets the IPv6 address and sends it to the appliance as vCenter IP address. The appliance does not support IPv6 and hence fails to authenticate using this address. The workaround for both these issues is to log into the vCenter server via non-local IP address of the vCenter server.
The UI first tries to authenticate using the ticket to the appliance. This always fails till the appliance setup is finished, i.e. the vCenter server credentials are set in the appliance because the appliance has no way to authenticate the ticket. In this case, after the first attempt fails, it displays an error and then asks for the vCenter server password so that it can use it to authenticate. Can you provide more information about your setup and the error messages that you see when it fails to connect? Is the appliance already configured with vCenter credentials? Does it ask for vCenter server password after the failure? What is the error message that is displayed?
IT WORKS!!!!
These are steps and O.S.'s I used.
Firstly I uninstalled , rebooted and reinstalled VCenter.
I also added a DNS record for the ESXi host IP on our DNS server. Now it resolves to esxi.domain.local. I did notice there was an old reverse lookup in DNS to another hostname on he same IP so I deleted that old entry.
VIClient - XP Pro SP2 32-bit, Domain member.
VCenter Server - Server 2003 32-bit SP1 inside a VM on the ESXi host. Domain member of our SBS2003 server.
VMDR backup appliance - VM on the ESXi host and kept default username and password intact ()
Our DNS server is a SBS 2003 VM on a ESX3.5 host elsewhere on the network (production network host).
Everything is on the same subnet (192.168.222.0/24 in our case).
I used the SBS domain administrator username and password to log into VCenter using VI client and used the IP address of the VCenter server. I also used the IP of the DR appliance.
To connect to CIFS shares as a backup destination I used file:// and username\password was administrator and it's password. I tried domain\administrator and that wouldn't work.
ipaddress\share
It's currently running 2 backups to our NAS (running MS Web Server 2003).
I hope this helps someone.
Edit: The crossed out parts are slash slash ipaddress slash share
i never had a problem connecting when runing vi client on 32bit XP its only when the vi client was run on vista or 64bit windows that it wouldnt connect
Were you connecting to vCenter server using IP address or DNS name? Do you have IPv6 enabled on Vista?
I called into Tech Support and they have confirmed the following:
Vista & Windows 2008 (32bit/64bit) vSphere Client has issues with the Data Recovery Plugin. Sometimes the plugin doesn't register, sometimes it does. When it does register, you will not be able to connect your Data Recovery appliance. It does however work on XP. Once you've registered the appliance from an XP client, and walked through the "Getting Started Wizard" you can access the appliance from the Vista/Windows 2008 vSphere Client without issues (you may need a restart of your vSphere client).
The tech confirmed with an internal VMware BUG ID # 412552.
Hope this helps.
Now that I know to use the IP address "verses localhost" when logging into the VC svr from the VI client on the VC srv I can now connect to VDR. I'm running VC srv as a VM on 2008 64bit with a 32bit ODBC connection to SQL2005.
This did help me, I personally had a heck of a time connecting to a "Network Share" with VDR. Tech support told me he had to install vSphere in his lab so he could test (yikes!). My biggest hangup was that just connecting to VDR is trouble unless I'm running vSphere Client from a Windows 2003 server (vCenter is running on a 64-bit Windows 2008 physical server. And even then only while logged into the vSphere client as a local admin and using local account credentials to "Add a Network Share" would it work. This is definately an early rev of this product.
Well I updated to 1.01 of the product to fix the snapshot issues only to now get this error from an x86 Vista client.
Ho Hum, I will install the plugin from 2003 and see what happens. I look forward to version 1.02
Ok update. I tried on 2003 and it failed too. So I took a look and it had picked up an old hostname from DHCP.
I set a static IP and changed the hostname. It then worked fine from Vista client, all is now well.
So if you have the same issue try a static IP and make sure there is no old hostname hanging around in DNS.
Sono fuori ufficio. Rientrerò l'11/08/09. Per qualsiasi necessità potete contattare VEM Sistemi al +39 0543 725005
Cordiali saluti
Alessandro Di Fenza
I'm out of office. I'll be back on 11/08/09. For any issues please call the following number: +39 0543 725005
Kind regards
Alessandro Di Fenza
I had the same problem. DNS name resolution was not correct. As workaround / for testing, enter the name / IP address of your appliance into the hosts file of the client.
Hi all. I had the connection problem too, but it worked out with using a account with long and complex enough password! Running vCenter on Windows Server 2008 x64 as a VM.
I have the same problem also with new version VMware Data Recovery 1.0.2
vCenter Server 4 ---> Windows 2003 R2 SP2 32 bit
vSphere Client 4 ---> Windows XP 32 bit
I will check if someone have a solution
All,
Just to make sure - when you upgrade, it means that you reinstall
BOTH the VDR appliance on the ESX/ESXi host and the vSphere Client
plug-in on the Windows PC.
In addition, you should connect using the IP
address as opposed to the FQDN. (Open the console for the VM and it
will show you the IP address). Both should be version 1.0.2.
This
version also fixes the issues on vCenter Server running on non-default
ports, so that is no longer an issue
Three suggestions that I have using vSphere Client:
1) Connect to vCenter Server using its IP address and then try
connecting to the VDR appliance using its IP address- any difference?
2) Connect directly to the ESX host running the VDR appliance using its
IP address and then try connecting the VDR appliance using its IP
address any difference?
3) With this release, you can create a datarecovery.ini file in
Plugins\Data Recovery folder on the Windows PC running vSphere Client.
Using this file , you can change the connection timeout using the
following key-value pair
ConnectionTimeout=x
Where x is the timeout in milliseconds. The default value is 60000 (1
minute), you can increase this to 600000 (10 minutes) and see if that
makes a difference.
(Please note that the keys in the .ini file are case-sensitive.)
Restart the vSphere Client and once this done, retry #1 and #2 above
One more thing
In 1.0.2 you can hold shift while clicking on the Refresh link. This will open the location of the
log file. Browse to that file and open it up - it should provide the error why the client is unable to connect.
One more thing - username and password cannot contain non-ascii characters.
1) I have tryed but same result: no connection to the Data Recovery DR VM
I connect the VC Client using ip address to both the VC server and the DR VM
DR VM is version 1.0.2
plugin is version 1.0.2
username and password are both with ascii characters
I have tryed local users and domain users with administrators privilege
DR VM can ping vCenter Server and there are no firewall, VM and vCenter server are in the same subnet
I have also tryed vCenter Client from the vCenter Server
this is the log (DataRecovery_0.log):
09/14/2009 09.16.46 > VC Server Address : '192.168.100.210'
VC Server IP Address: '192.168.100.21009/14/2009 09.18.06 > Connecting: Retrieving appliance selection...
09/14/2009 09.18.07 > VC Server Address : '192.168.100.210'
VC Server IP Address: '192.168.100.21009/14/2009 09.18.15 > Connecting: Retrieved appliance selection:
VM Name: VMDataRecovery
IP Address: 192.168.100.80
Host Name: localhost.localdom09/14/2009 09.18.16 > Connecting: VM power state is: PoweredOn
09/14/2009 09.18.16 > Connecting: Attempting to get NFC ticket using IP address...
09/14/2009 09.18.16 > VC Server Address : '192.168.100.210'
VC Server IP Address: '192.168.100.21009/14/2009 09.18.16 > Connecting: Retrieved valid NFC ticket
09/14/2009 09.18.16 > Connecting: Attempting to connect to: 192.168.100.80
09/14/2009 09.18.16 > Connecting: Attempting to open the connection...
09/14/2009 09.18.16 > Connecting: Could not open the connection
09/14/2009 09.18.16 > Connection attempt failed
09/14/2009 09.18.17 > VC Server Address : '192.168.100.210'
VC Server IP Address: '192.168.100.21009/14/2009 09.18.28 > Connecting: Asking user for password...
09/14/2009 09.18.33 > VC Server Address : '192.168.100.210'
VC Server IP Address: '192.168.100.21009/14/2009 09.18.33 > Connecting: Attempting to connect again...
09/14/2009 09.18.33 > Connecting: Attempting to open the connection...
there is a way how debug DR VM ?
(/var/log/messages and /var/vmware/datarecovery/* do not contains errors)
2) Connecting directly to the ESX host running the VDR appliance ... it works ... only one time, I have tryed a second time and do not work more !
Thanks, regards
From the log it looks like the appliance is not responding or the data recovery service is not running. The message: "the operation is not allowed on non-connected sockets" indicates that a
low-level connection could not be established. This happens before any authentication occurs, so it is not related to credentials etc. So , at least we have gotten that out of the way
Some suggestions:
1) From the PC running vSpehere Client, can you ping 192.168.100.80? ( I think the answer is yes)
2) Confirm that the data recovery service is up and running in the appliance. Open a console connection to the VDR appliance, login to the appliance (default password is listed in the VDR Admin Guide). Issue the command service datarecovery status. The response should be that is it running
3) If there is a firewall between vSphere Client and the VDR appliance, make sure port 22024 is open.
If there is still nothing that points towards a problem, we need to dig a bit deeper - the only way to figure out is to enable logging. Create the following file with the following option
/var/vmware/datarecovery/datarecovery.ini
Options
SetVCBLogging=6
Then, restart the engine using the command service datarecovery restart
And now try to connect to the appliance using the UI.
Use datarecovery-support script to generate the tar file of all the logs.
From the log it looks like the appliance is not responding or the data recovery service is not running. The message: "the operation is not allowed on non-connected sockets" indicates that a
low-level connection could not be established. This happens before any authentication occurs, so it is not related to credentials etc. So , at least we have gotten that out of the way
Some suggestions:
1) From the PC running vSpehere Client, can you ping 192.168.100.80? ( I think the answer is yes)
yes I can ping 192.168.100.80
2) Confirm that the data recovery service is up and running in the appliance. Open a console connection to the VDR appliance, login to the appliance (default password is listed in the VDR Admin Guide). Issue the command service datarecovery status. The response should be that is it running
<root@localhost> service datarecovery status
datarecovery (pid 3054) is running...
3) If there is a firewall between vSphere Client and the VDR appliance, make sure port 22024 is open.
If there is still nothing that points towards a problem, we need to dig a bit deeper - the only way to figure out is to enable logging. Create the following file with the following option
/var/vmware/datarecovery/datarecovery.ini
Options
SetVCBLogging=6
Then, restart the engine using the command service datarecovery restart
And now try to connect to the appliance using the UI.
Use datarecovery-support script to generate the tar file of all the logs.
there is no firewall between vCenter Server and client.
I have created the file /var/vmware/datarecovery/datarecovery.ini in the VDR Appliance
<BOF>
Options
SetVCBLogging=6
<EOF>
then I typed "service datarecovery restart"
tryed to connect using plugin....same error
then connect to VDR Appliance console and typed "datarecovery-support" ... I attach the file datarecoveryLogs-200909151238.tar.gz and the file DataRecovery_0.log
Thanks, Regards
Sorry azmir, one question about the file /var/vmware/datarecovery/datarecovery.ini
What is the syntax for "Options" ? Need to be in brackets ?