SRM 5 - VRMS database connection issue

[roniva3]

I pulled down an evaluation of SRM 5 yesterday and the installation went off without issue.  The same, however, cannot be said for the installation of the bundled vSphere Replication Management Server.  The Appliance deploys okay but I cannot get it to connect with the database to save my life.

Here is my environment:

• Dell PowerEdge T-105 (4-core & 8GB ram) running ESXi 5 (without the recent patch)
  
• vCenter 5 running on a virtual machine with the database hosted locally (lab-vc\vim_sqlexp is the SQL instance)
  
• SRM 5 running on the vCenter server using a seperate database but in the same SQL instance as the vCenter database
  
• VRMS 5 appliance running on the same host with the database, like the SRM database, a seperate database but in the same SQL instance as the vCenter database
  

My issue seems to be with the JDBC connection from the appliance to the database.  I pre-created the database and the schema as the SRM5 documentation would indicate and I've made sure the user information, the port information, and the permissions/ownership was correct.  I made sure there was no firewall issues and that the SQL server was set to mixed mode authentication.  I even looked at the URL it created and tried tweaking that based on some Microsoft articles on JDBC connections.  Nothing seemed to help.  I then tried to look at the logs on the appliance as per the troubleshooting section of the SRM5 doc and the path they indicate - /opt/vmware/vrms/logs - didn't exist.  And none of the logs I could find had any info on the connection issue.

So my question is, what am I missing?  I know it's still early days here, but does anyone have VRMS up and running yet?  Was there anything special that needed to be done?

Any help would be greatly appreciated.  I am not a SQL guy so there is likely some big glaring thing that I didn't know I needed to do to get this working.

Thanks,

Ron Brown

[darkkavenger]

Hello,

I am running into the very same problem. At first I tried to manually create the VRMS_DB database on each SQL Express on which the vCenter server database is running, to no avail. I then used a dedicated SQL server, with no luck again. The documentation is rather silent about the way DB should be configured.

I need to test whether SRM 5 will be our future DR protection solution. So far it seems rather complex to implement.

Thanks for your help,

Max

[srinut31]

Hi Friend,

              I installed SQL Express"SQLEXPR_x64_MNU.exe" for srm5 database i didn't face any problem. while installing you need to select new instance and create a new instance for SRM5 database. While adding ODBC u need to select SQL Silent.

[darkkavenger]

Hello Srinivas,

are you referring to creating a new instance specifically for SRM 5, or for the vRMS database?

Thanks,

Max

[roniva3]

Well, I have resolved my issue but I still have no idea what the underlying cause was.  Here's what i did.

DISCLAIMER: The information below should in no way be considered instructions on how to set this up in a production environment.  This is simply a recount of what I did to get things working in my LAB.

1. Installed SQL 2008 R2 Standard on a seperate Windows 2008 R2 virtual machine.
   
2. During the SQL installation, I ...
   
   1. Selected the default instance
      
   2. Chose mixed mode authentication
      
   3. Told it to install everything with the default configuration (as I mentioned before, I'm not a SQL guy and I didn't want to miss a needed component).
      
3. When the installation finished, I rebooted the VM (to get all the services started cleanly).
   
4. When the server came back up, I went into the SQL Server Configuration Manager (under SQL Server Network Configuration - Protocols... - TCP/IP - IP Addresses) and made sure that the port was set to 1433 for all IP addresses.
   
5. I then went into the firewall on the server and created an inbound rule for TCP port 1433.
   
6. Finally, I went into the SQL Server Management Studio and
   
   1. Created the login (i.e. vim_vrms)
      
      1. After creating the DB, I went back in here and changed the default database to be the VRMS database.
         
      2. I also went to the Server Roles tab and made this login a sysadmin (I'm sure this is overkill but again, not a SQL guy)
         
   2. Created the database (named the same as the login - vim_vrms)
      
      1. DO NOT set the login above as the database owner - leave it as default
         
   3. Created the database user (named the same as the login - vim_vrms)
      
      1. I associated it with the login I created above
         
      2. I assigned it the db_owner role
         
      3. I left Default Schema and Owned Schemas blank for now
         
   4. Created the schema (named the same as the login - vim_vrms)
      
      1. I put the database user as the Schema Owner
         
   5. Go back into the database user properties for the user created above and change the default schema to the one created above
      
   6. Go back into the login properties for the login created above and ...
      
      1. Change the Default database to the one created above
         
      2. Go to the User Mapping and look for the user name.
         
         1. All three items in the table (Database, User, Default Schema) should have the same name.
            
         2. db_owner and public should be checked below
            
   7. Go back to the Database properties - Permissions tab and you should see the user you created and if you click "Effective", you will see all the permissions granted to this user.
      

With that done, the configuration on the VRMS side was easy.  The only thing I needed to do was to use the IP address of the SQL server rather than the server name.

So that is what I did to get past my problem.  I followed the same "Step 6" stuff above when I was using SQL Express so I'm not certain if it is a SQL Standard vs. SQL Express functionality thing or if it's a Default Instance vs. Named Instance thing.  But my testing can resume.  I hope this helps!

And to repeat myself...

DISCLAIMER: The information above should in no way be considered instructions on how to set this up in a production environment.  This is simply a recount of what I did to get things working in my LAB.

[srinut31]

Dear darkkavenger,

Your right Create new Database for VRMS. That should work.

[JohnnyBravo]

WIth SQL Express you should also make sure that the local and remote connections option is selcted in the SQL surface area configuration.

I have this working using SQL Express 2005 on the same server as SRM 5. I set up a new instance as default and works.

JB

[kruddy]

Thanks to Roniva3, that helped out quite a bit.

Another key tidbit I picked up: the default instance must be selected, named instances do not seem to work whatsoever.

[buckmaster]

THANK YOU roniva3

Key point is to remember to have sql and or sql express set to mixed mode.  roniva3 mentioned it above but I missed it.  This is especially true with sql express.

[ph0bia]

I finally managed to beat it as well, I used roniva3 instructions from above but missed one thing, in SQL 2008 Express by default the Legacy TCP/IP is disabled and only the new native clients are enabled for TCP/IP.  So in the end these are all of the things I needed to do to make it work:

- Install SQL server, using default instance (named instance will NOT work no matter what)  I placed mine on the SRM boxes on each end.

- Mixed mode authentication is required for SQL, you cannot use windows authentication for this database

- Follow roniva's instructions for creation of database and user, and assignment of permissions (see the post earlier in this thread, and note the disclaimer!).

- In SQL Server configuration manager make sure that SQL Server Network Configuration -> Protocols for SQL Server -> TCP/IP -> Enable

- When installing VRMS it asks for DNS servers, but does not add them to the configuration, you must manually fix in VRMS Network configuration

- VRM Site Name should match whatever you have defined for the site name in SRM

- Use IP Address for SQL Server, VRM Host,

- For vCenter server address it must match whatever you used in the SRM site connection, if you used IP there, use IP here, otherwise use FQDN

- For the vCenter Server Username, do not prefix the username with domain name in  mydomain\myuser format, use the username only

If it is any consolation getting the VRS servers working is much easier!  🙂

Hopefully someone at VMware will take all of the information provided in this thread and use it to write some better documentation for this product, and take this knowledge to make the product more sane.

Corporations today utilize consolidated SQL clusters which they prefer to use to host all of their databases.  It is ideal to be able to use these for all such databases, as they are more likely to be properly configured, tuned, secured, backed up, patched, etc.  VMware's lack of support for named-instances and the like is extremely frustrating and needs to be addressed.  VRMS is a SUSE appliance, there should be an option for local Postgres or MySQL as well if you just want a quick-and-easy deployment...

[MD2000]

Same thing here. I kept hitting the wall on "Please check provided DB information" configuring VRMS database.

Doh! TCP/IP is disabled for SQL Express by default - so the VRMS appliance, an outside (v-)box, does not get a reply on 1433.

I installed a separate instance of SQL Express on the VCenter box. Default instance, MSSQLSERVER

Used steps 6 above to configure database/user/schema VRMS on this instance.

Use config manager, open MSSQLSERVER instance, network connections, ENABLE TCP/IP

Finally, this worked.

Thank you for the database config process!!

[jwr51]

Thanks for this Ron. I was completely stuck but I followed your instructions to the letter and now I can continue with my evaluation of SRM.

[YacoubIshak]

Thank you all

the steps that make it work for me are :

1)enable ip tcp/ip setting :

SQL Server Network Configuration -> Protocols for SQL Server -> TCP/IP -> Enable

2)db user settings as suggested by roniva3

3)use ip instead of FQDN (P.S: i used FQDN for the initial configuration but here it was not taking it )

official installation documents are missing a looot of information and misleading  . please vmware fix it