Cannot Pair VRMS Servers - VRM Server generic error. Unexpected status code: 404

[DanielRollinsEl]

I have been setting up SRM as per the documentation and am at the part where I have a configured VRM server on each side. My next step on the vSphere Replication tab is #3 "Configure VRMS Connection". When I click the "Configure VRMS Connection" link I get a dialog box that says: "Do you want to configure VRMS connection?". I click "Yes" and I get another dialog box that says: "VRM Server generic error. Please check the documentation for any troubleshooting information. The detailed exception is: 'Unexpected status code: 404'."

Has anyone seen this before? Do you know how to solve it?

Thanks

[bobalob]

Hi,

We are seeing the same issue when trying to pair the VRMS servers - Generic Error: 404

Using the same steps as you have detailed. We have tried deleting the servers and redeploying with no luck. Both vrms servers can ping each other by name and IP. When connected to the vSphere server on either site, they both show "VRM Servers are not paired" in summary on the local site and "Disconnected" on the remote site.

I'll pull the logs and get more detailed information if needed.

Regards,

Dave.

[stormvm]

Hi,

I am also seeing exactly the same error. I am currently attempting to trial this for my organisation. However I cannot get this to work.

I'm getting exactly the same "generic error 404" when configuring VRMS connection.

I have checked ports as shown in the SRM Admin guide, and I can telnet into both VRMS servers from each other, and also from the respective Virtual Centre's on the ports required

If I find a solution I'll post it here, hopefully someone may have already tackled this and will let us know the solution.

As mentioned above I can also post my logs if necessary, if anyone could shed anylight on the error

[Smoggy · Accepted solution]

think this is a known bug that should have made it into the "known issues" section of the release notes but didn't for some reason i'll check that internally.

It seems that during SRM installation, vCenter was specified by DNS, while during VRMS configuration vCenter was specified by an IP address. These two must match. i.e if you use DNS(FQDN) in one place use it in the other as well. In my setup i've used IP addresses for both entries during the install process and did not see any issue.

If you cannot recall how you defined vCenter in the SRM installer screen then I guess the quickest test is to redeploy and configure the VRMS appliances and do the opposite of what you've just done i.e if you just used FQDN in the VRMS screens when telling it about vCenter use the ipaddress instead and vice versa.

[pantana85]

Thank. I solved this issue following your advice.

[tspero]

We are also experieicing this same error in SRM 5.0, and deleting / re-deploying everything using IP addresses rather than FQDN did not solve the problem.  We are also seeing some very ugly errors when trying to un-register the VRMS from vCenter (to prepare for our 3rd attempt to make vSphere replication work).  Here's the actual error we see when unregistering.  The other error we experience when trying to establish the VRMS connection is identical to what was posted previously.  One site seems to connect find, however the other site shows status "Disconnected" and they will not pair for the VRMS connection.  Any assistance is appreciated!

Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@70922804: display name [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@70922804]; startup date [Thu Oct 06 21:45:09 UTC 2011]; root of context hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [com/vmware/vim/binding/vmodl/context.xml]
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
INFO: Bean factory for application context [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@70922804]: org.springframework.beans.factory.support.DefaultListableBeanFactory@1be1a408
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1be1a408: defining beans [context]; root of factory hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext doClose
INFO: Closing com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@70922804: display name [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@70922804]; startup date [Thu Oct 06 21:45:09 UTC 2011]; root of context hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.support.DefaultSingletonBeanRegistry destroySingletons
INFO: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@1be1a408: defining beans [context]; root of factory hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@5bcdbf6: display name [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@5bcdbf6]; startup date [Thu Oct 06 21:45:09 UTC 2011]; root of context hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [com/vmware/vim/binding/vmodl/query/context.xml]
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
INFO: Bean factory for application context [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@5bcdbf6]: org.springframework.beans.factory.support.DefaultListableBeanFactory@71060478
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@71060478: defining beans [context]; root of factory hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext doClose
INFO: Closing com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@5bcdbf6: display name [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@5bcdbf6]; startup date [Thu Oct 06 21:45:09 UTC 2011]; root of context hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.support.DefaultSingletonBeanRegistry destroySingletons
INFO: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@71060478: defining beans [context]; root of factory hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
INFO: Refreshing com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@dcb52ae: display name [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@dcb52ae]; startup date [Thu Oct 06 21:45:09 UTC 2011]; root of context hierarchy
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [com/vmware/vim/binding/vim/context.xml]
Oct 6, 2011 9:45:09 PM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory
INFO: Bean factory for application context [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@dcb52ae]: org.springframework.beans.factory.support.DefaultListableBeanFactory@14fdb00d
Oct 6, 2011 9:45:09 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@14fdb00d: defining beans [context]; root of factory hierarchy
Oct 6, 2011 9:45:13 PM org.springframework.context.support.AbstractApplicationContext doClose
INFO: Closing com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@dcb52ae: display name [com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl$NonValidatingClassPathXmlApplicationContext@dcb52ae]; startup date [Thu Oct 06 21:45:09 UTC 2011]; root of context hierarchy
Oct 6, 2011 9:45:13 PM org.springframework.beans.factory.support.DefaultSingletonBeanRegistry destroySingletons
INFO: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@14fdb00d: defining beans [context]; root of factory hierarchy
[Fatal Error] extension.xml:1:1: Premature end of file.
Unable to register vCenter extension: Internal error.
Detailed trace:
com.vmware.jvsl.cfg.ConfigException: Internal error.
at com.vmware.jvsl.cfg.CommandFactory.createCommand(CommandFactory.java:134)
at com.vmware.jvsl.cfg.ExtReg.main(ExtReg.java:46)
Caused by: com.vmware.jvsl.cfg.ConfigException: Internal error.
at com.vmware.jvsl.cfg.CommandFactory.getExtensionData(CommandFactory.java:152)
at com.vmware.jvsl.cfg.CommandFactory.createCommand(CommandFactory.java:122)
... 1 more
Caused by: org.xml.sax.SAXParseException: Premature end of file.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:249)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:284)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:180)
at com.vmware.jvsl.cfg.CommandFactory.getExtensionData(CommandFactory.java:145)
... 2 more

[stormvm]

Thanks for the replies on this,

I did manage to fix this before I had seen the responses but just to reiterate what has been said above.

The generic error occurred when we used IP addresses in the VRMS configuration in the "vCentre server address field". this field must be identical to the names used to build vCentre initially. Using FQDN will not work either unless vCentre was built using FQDN.

Its a bit of a knightmare becuase each time you want to change anything in VRMS configuration you need to set up a blank database etc.

However once we used hostnames in here everything worked ok, only because virtual centre was built using hostnames. VRMS must be able to communicate using DNS or entries in hosts file to each VRMS and virtual centre(s) for this to work.

Once this was complete we could then pair the VRMS connections.

Thanks for your help here

[Smoggy]

given that the workaround is working for everyone else this suggests to me there is something else fundamentally wrong with your setup.

my advice would be:

- don't attempt to re-use any of the existing VRMS databases, delete and recreate after you have deleted the appliance

- if you've gone through a few unsuccessful attempts and haven't got anything else configured consider re-installing SRM as well, also with a clean database

- install SRM with vSphere Replication selected (both sites)

- pair SRM servers

- deploy VRMS appliances using IP credential for vCenter (ensure you have done that during the SRM install phase as well...i.e use IP for vCenter id)

- login to each VRMS appliances and complete the configuration tasks (security cert generation, database connection, service startup - check services running, UI will show this)

- pair VRMS appliances together.

[DanielRollinsEl]

Smoggy,

Thank you, this worked perfectly. I can now use SRM.

[tspero]

I think the reason why the VRMS appliance for the DR site seems to be setup properly and the VRMS appliance for production seems to be having issues is likely due to the DR site being fully upgraded to ESXi 5.0, while we still have one host left in production on ESXi 4.1u1.  We're upgrading the last host in production to 5.0 this weekend so we'll give it another try after then and see if that solves the issue.

[anh2lua]

Thanks.

I unregistered both the VRMS appliances from both ends. Removed the databases from SQL. Re-registered them with the FQDN for vCenter Servers. SQL Server has to be IP addresses.

It worked this time.

We also have RecoverPoint in our environment and this VR Manager cannot see the LUNs protected by RecoverPoint from the remote site. That means I will have to create new LUNs and add them to VMs to store my replicated VMs using VRMS.

[syedwaqar]

Dear All,

After following all the steps describe here with all the necessary FQDN technicalities, I was unable to pair VRM Servers, and its show DISCONNECTED in status,

"but when I logged on the deployed OVF of VRM Server and took console of it and then enter my credentials in CLI for Login process."

Above process resolved my issue, If some of you getting same then try this also.

[DanielRollinsEl]

I am out of the office on Paternity Leave. I am planning on returning on Mon, 2012-01-09

[BobbyW]

Changing the vCenter server to the FQDN worked for me. Thanks Smoggy.

[llueder]

I had a similar error, code 503. the root cause was an incorrect DNS A-record. Removing the bogus entry and creating the correct one resolved it.

[DanielRollinsEl]

I am out of the office on Vacation.

[jordan57]

It worked for me after I update the vCenter to FQDN and deleted the database and recreated.

[yassinos]

Hi all,

If you get this two errors 404 or 503 when you try to pair the two VRMS Servers you can check the actions listed below :

- The two VRMS in each site must resolve the ip address of the remote site and can reach this site if it's a gateway between them.

- Make sure the dns record are correct in both sites.

- Add forwarders in each dns site.

The last thing to see if maybe all the previous actions don't resolve the problem :

Go to the database of the VRM and the SRM and check this tables : SRM database (PD_LOCALSITE & PD_REMOTESITE ) and  VRM(ConfigEntryEntity) see the vcenter address must meet in the two configuration, if you have a mistake in your VRM configuration you can change the value of this attribute by SQL management studio.

I hope that this can help someone.