VMware Cloud Community
cfsullivan
Contributor
Contributor
Jump to solution

VR Server Won't Start After Upgrade to 5.8

I upgraded my VR appliance from 5.5.1 to 5.8, but ran into this issue after the upgrade:

Unable to Start the vSphere Replication Management Server After an Upgrade (2107220) | VMware KB

I confirmed that the error mentioned in the article is present in hms-configtool.log. The biggest problem for me is the solution. I don't have experience running SQL commands and honestly I'm not used to using a Unix-y CLI. Are there any step-by-step dummy-type instructions for doing this?

We are upgrading from vCenter 5.5 to 6, Update 2 in a few days and my goal is to upgrade to VR 6.1.1, but I had to do this interim upgrade first.

Alternatively:

I am only replicating 9 VMs. Would it be easier to just get a new OVF and install a fresh one? Seems like overkill, but possibly not in my case. I didn't have much trouble setting this one up a few years ago.

I assume that I can't simply get the ISO for VR 6.1.1 and attempt an upgrade from the current state, but I guess I should confirm, just in case there is some kind of magic which will allow that.

Thanks in advance for any help.

0 Kudos
1 Solution

Accepted Solutions
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

If you take the route with deploying fresh VR appliances after the vCenter upgrade - this will definitely work and save you from entering the sql commands.

However, please note that the new VR appliances will automatically disable the old replications and when you configure the new replications, there will be some period of initial full-sync. If you use the existing .vmdks at the target site as seeds only checksum will be calculated, so the actual data transfer won't be much, but be prepared to wait for the reads for the checksum calculation.

> I assume that I can't simply get the ISO for VR 6.1.1 and attempt an upgrade from the current state, but I guess I should confirm, just in case there is some kind of magic which will allow that.

You first need to fix the current state before attempting upgrade to 6.x (or whatever new release).

To open the SQL prompt:

1. Establish SSH session to the appliance (I don't remember if SSH is enabled or disabled by default at VR 5.8, but there should exist documented steps for enabling ssh). It will be much more easy to type the sql commands in ssh session compared to using the VM console.

2. Type /opt/vmware/vpostgresql/current/bin/psql -U vrmsdb

3. Enter each of the upgrade statements one by one followed by semicolon (;). Be careful to not paste multiple statements at once, as some of these are changing the schema, and if something fails you can retry.

It might be helpful to have a second SSH session opened to browse through the sql file, or to copy it with scp and copy each individual statement via some text editor.

I haven't tried if copying all the statements to a new file (without the line insert into PendingChangeRecordEntity...) and passing that file to psql would work or not.

4. Type \q to exit the sql prompt.

5. Disable the ssh access if necessary.

Regards,

Martin

View solution in original post

0 Kudos
4 Replies
mvalkanov
VMware Employee
VMware Employee
Jump to solution

Hi,

If you take the route with deploying fresh VR appliances after the vCenter upgrade - this will definitely work and save you from entering the sql commands.

However, please note that the new VR appliances will automatically disable the old replications and when you configure the new replications, there will be some period of initial full-sync. If you use the existing .vmdks at the target site as seeds only checksum will be calculated, so the actual data transfer won't be much, but be prepared to wait for the reads for the checksum calculation.

> I assume that I can't simply get the ISO for VR 6.1.1 and attempt an upgrade from the current state, but I guess I should confirm, just in case there is some kind of magic which will allow that.

You first need to fix the current state before attempting upgrade to 6.x (or whatever new release).

To open the SQL prompt:

1. Establish SSH session to the appliance (I don't remember if SSH is enabled or disabled by default at VR 5.8, but there should exist documented steps for enabling ssh). It will be much more easy to type the sql commands in ssh session compared to using the VM console.

2. Type /opt/vmware/vpostgresql/current/bin/psql -U vrmsdb

3. Enter each of the upgrade statements one by one followed by semicolon (;). Be careful to not paste multiple statements at once, as some of these are changing the schema, and if something fails you can retry.

It might be helpful to have a second SSH session opened to browse through the sql file, or to copy it with scp and copy each individual statement via some text editor.

I haven't tried if copying all the statements to a new file (without the line insert into PendingChangeRecordEntity...) and passing that file to psql would work or not.

4. Type \q to exit the sql prompt.

5. Disable the ssh access if necessary.

Regards,

Martin

0 Kudos
cfsullivan
Contributor
Contributor
Jump to solution

Thanks, I appreciate the quick response.

Would it be possible to comment out line 7 in in the SQL script and just run the whole script? I'm guessing there's a reason not to, but figured I should check. I see that I am able to SSH to the appliance by the way, so thanks for that suggestion.

If I were to retire the failed VR appliance and install a new VR appliance from scratch, would I run into any problems if I were to use the same host name and IP address? Also, is there any cleanup involved? In vCenter the replicated VMs are aware that they can't replicate. I'm not seeing anything in vCenter Web Client that would allow me to un-register the failed VRA and I can't stop the replication without the appliance working. I probably should add that this VRA is the only one we have, it's doing all of the replications and management, if that makes a difference in how I approach this.

0 Kudos
cfsullivan
Contributor
Contributor
Jump to solution

Actually, think you may have already answered my question as to whether or not this script could be run whole with the "bad" line commented out in section 3 of your reply.

0 Kudos
cfsullivan
Contributor
Contributor
Jump to solution

The information you gave me was very helpful. I used Putty to run 2 SSH sessions as you suggested. It has a clipboard which allowed me to copy all the commands into a text file on my desktop then pass them to Postgres one at a time with (;) at the end of each.

Unfortunately, for whatever reason, this didn't solve the problem. In fact something I did must have made it worse because I can't even log into the VAMI now, though I can still log in at a terminal.

I had asked earlier about cleanup if I wanted to start from scratch with a new VRA, but then I noticed that there is an option within VAMI to disassociate the appliance from vCenter. Of course now I can't log in to use that, but I just read that I can use MOB, which should be easy enough.

vCenter will be upgraded to 6 U2 over the weekend and I'll deploy the new VRA on Monday.

0 Kudos