vCenter 5.5 e VDP 5.5.1: Unable to find this VDP in the vCenter inventory

[Francesco2011]

When I try to registration a new VDP 5.5 on vCenter 5.5 I have the error: Unable to find this VDP in the vCenter inventory.

For user, I have used "administrator@vsphere.local" or "vsphere.local\administrator" or "mydomain\administrator" and the correct password for all user. I don't understand where is the problem. The vCenter is on the windows 2008R2 64bit and I have deployed the VDP from webclient and vsphere client into different tests.

Please help me!

Thanks!

Francesco

[vmrulz]

Are you using the fat client or the web client? I've got the same versions setup and I'm able to find it and use it via the web client but not in the fat client. From what I've heard from good sources the web client is their long term client and the fat client will be going away before long. The web client is getting better but it still has its share of glitches and missing things.

[vmrulz]

I misunderstood your question. Have you made sure your domain\account has administrator perms at the top of object in vcenter? Also make sure SSO is setup to use your domain as the default for credentials and not the local stuff.

[Kungkeno]

I have this exact same problem.

I as well have tried all the types of users you sugested to no avail. I have further problems with the mydomain\Administrator account though; I've explicitly added it to the administrators group in both vCenter and in the one host that vCenter manages (where VDP is deployed) but it does not seem to be working properly. When i try to log in to the web client of vcenter with the mydomain\Administrator credentials i just get "Provided credentials are not valid." however if i'm loged in to a computer as the domain administrator and tick the box "use windows session authentication" i'm able to log in (The same goes for loging in to the esxi host directly through vSphere client ). I should mention that our AD is configured in a Swedish environment and even though you may log on to windows computers using "Administrator" this user is actually called "Administratör" (i.e with an ö) which is also how it appears in vCenter. I suspect this might have something to do with it.

I've also tried adding other users from our AD as vsphere administrators but none of these can log in at all. Maybe the ones i had weren't all that good to begin with but I'm really running out of ideas now.

[Francesco2011]

Hello!
I don't know if the one I used is the correct procedure but I do so I solved it!

First I added the local administrators group on the list of permissions in the cluster. Then I deployed again the vdp adding the full domain name (eg. vdp.mydomain.local).

I have used the user administrator@VSPHERE.LOCAL and the test connection is passed. On another infrastructure I had the same problem but I have added only the administrators group and the procedure not work. So I think that the deployment with the fullname is the solution. Verified and confirmed, if possible.

Francesco

[Kungkeno]

I don't have a cluster configured but i will try this procedure with the vsphere.local\administrators group added to the list of permissions of the vCenter server. May i ask how you have the vCenter authentication configured? I have added ours to our active directory domain through the vcenter server web console, however the Domain does not automatically show up in the vcenter web client. Instead i have to manually add it from  Home/Administration/Configuration/Identity Sources, is this also the case for you? It kinda feels like have something miss configured but from reading the administrators guide et.c i can not seem to pin point it as i have followed these to my best ability while deploying the vCenter as well as the VDP.

On another note; I have had some problems deploying the VDP in the first place. At first i tried deploying it from a virtual machine running on the Host i was deploying the VDP to. This failed any way i went about doing it. I then tried to deploy it from a physical machine which worked but took a significantly longer time (something like 2 hours). Is it the case that one can not deploy the VDP from a virtual machine running in the host one tries to deploy it from? I have not been able to find information on this problem.

[Kungkeno]

After adding the user group "VSPHERE.LOCAL\Administrators" to the permissions list in vcenter and deploying the VDP with the FQDN: "vdp.mydomain.local" (before i had only used "vdp") i was able to register the VDP with vCenter. Thus i think one of these two or maybe both are necessary for a successful deployment. The group thing feels a bit strange to me as the vsphere.local\Administrator user was already in the list (albeit the whole user permissions is slightly confusing to me atm) so my money is on the FQDN which i can understand and should have understood right away.

In short: I confirm that Francesco's suggestions worked.

[mobcdi]

I was stuck on this for a while as well and deploying the ova template using the FQDN vdp name in the deployment wizard instead of something unique or any other naming scheme for vm's i might have worked for me in the end

It looks like the VC search is by FQDN hostname instead of vNic IP address or other destinguishing properties of the vm configured within the vm itself

The VDP admin guide to be fair does say the following on pg 20 step 11, I just didn't equate Name and FQDN Name as being the same thing during the deploy wizard. I'm not sure if you can rename the appliance after initial configuration is complete to match any naming scheme you use for vm's in your VC DC

On the Select name and folder screen, enter the name for the VDP Appliance (this must match the entry configured on the DNS Server) and click on the folder or datacenter in which you want it deployed. The VDP Appliance Name should not be changed after installation. Click Next.

[Kungkeno]

Yes indeed, had "name" been replaced with "FQDN" in this paper i would likely never had encountered this problem. Perhaps VMware could actually change this to avoid confusion?

[mobcdi]

I've sent off an email to the doc feedback address suggesting a clarification and adding the resolution to the troubleshooting section of the doc for the error

[GSparks]

This issue is because the VDP appliance requires that the forward and reverse DNS be defined prior to the OVA being deployed.

The following symptoms can be found in different files:

1.     In the /etc/hosts file, the IP address for the VDP appliance will exist, but the hostname will be blank.

2.     When viewing the /opt/vmware/var/log/vami/vami-ovf.log file, you will see the following entries near the end of the file:

     [info] [process id: 4062] Hostname property is not present, querying and setting hostname.

     [info] [process id: 4062] Output:Host name has been set to localhost.localdom

3.     In the /usr/local/avamar/var/vdr/server_logs/vdr-configure.log file, the following entry can be found:

ERROR [http-nio-8543-exec-9]-config.VDRApplianceCurrentConfig: Unable to get the set host name and domain.

1. java.net.UnknownHostException: localhost.localdom: localhost.localdom: Name or service not known

at java.net.InetAddress.getLocalHost(Unknown Source)

at com.emc.vdp2.config.VDRApplianceCurrentConfig.getNetworkDetails   

:q(VDRApplianceCurrentConfig.java: 153)

at com.emc.vdp2.config.VDRApplianceCurrentConfig.init(VDRApplianceCurrentConfig.java:60)

at com.emc.vdp2.config.VDRApplianceCurrentConfig.<init>(VDRApplianceCurrentConfig.java:47)

at com.emc.vdp2.config.VDRWorkflowFactory.getConfig(VDRWorkflowFactory.java:247)

at com.emc.vdp2.config.VDRWorkflowFactory.getConfiguration(VDRWorkflowFactory.java:53)

        at com.emc.vdp2.config.services.ConfigurationService.getConfiguration(ConfigurationService.java:110)

The easiest solution for this issue is to redeploy the OVA after the required DNS entries have been created.

To test whether your DNS is properly configured, you can reference the VDP Admin Guide, page 15.

[Pb81]

I would suggest another way of solving it.

Just reconfigure ip address of the appliance under the configuration tab once fixed the dns issue. It will make VDP re-register correctly without reinstalling it.