Missing Configuration section in VAMI, vCenter shows Enabled Not Accessible after upgrade from 5.5 to 5.8

[ThepHuck]

Hello everyone!  I'm having a bit of an issue that I can't seem to find a fix for anywhere.

I have a lab with two vcsa boxes running 5.5 U2d and wanted to upgrade to SRM 5.8.  I started at the 5.5.1 VRA (I don't recall actual build number, whatever was with SRM 5.5.1), mounted the 5.8 ISO on both sides, rebooted both, ran the update from CD (followed the official upgrade steps), but after reboot, both vCenters show "Enabled (Not Accessible)" and still list it as 5.5.1.

I validated the VR service is running.  I followed this thread, regenerated certificates for BOTH vCenters & BOTH VRAs: vsphere replication upgrade 5.5 to 5.8 Server Enabled (Not accessible)  Still no joy.

I checked the MOB and the IP is correct.  I tried to check /opt/vmware/hms/conf/extension.xml for the thumbprint and the file doesn't exist on either box, only thing there is extension-template.xml.

On one side, I reset the vCenter database (/usr/sbin/vpxd -d from VMware KB:    Resetting the vCenter Server embedded database repository for vCenter Server Appliance...), deployed a new VRA at 5.8, and had it register just fine.  It was then it occurred to me what I was missing: almost the entire Startup Configuration where you specify the vCenter (see attachment)

For grins, I unregistered the working 5.8 VRA from the "old" vcsa and tried to register it on the "new" vcsa, which it failed with lots of what looked like soap errors, assuming due to "new" vcsa already having a VRA registered.  I reregistered it back to the "old" vcsa and it's happy.  Installed SRM 5.8 (uninstalled 5.5 since I started with a clean db in the vcsa) and all is well on the "old" side.

I'm trying not to go this route on the "new" side, as I have a VDS, vSAN and twice as many hosts, so I don't want to recreate the vDC, cluster, add hosts, etc.  I copied /opt/vmware/hms/conf/extension-template.xml to /opt/vmware/hms/conf/extension.xml and rebooted.  The thumbprint shows up, but still no configuration stuff.

Anyone have any ideas?

[ThepHuck]

I was able to get it back, although it wiped the config, which I did expect.  The workaround to get vSphere Replication back on my "new" vcsa was basically this:

• Power off old VRA, delete from disk
• Deploy from OVF new 5.8 VRA with same IP address as original (call it .151), register with vcenter (still showed Enabled Not Accessible) - the console actually complained about vSphere Replication being registered already to vCenter, had to tell it to continue
• Logged into VAMI and had it unregister from vCenter, powered off, delete from disk
• Deployed another 5.8 VRA on .153, registered with vCenter - this time it didn't complain about vCenter already having vSphere Replication
• All is well

I probably could have done a "Reset Embedded Database" from the first OVF deploy, but I wanted to go through the complete wizard again.  After deploying it directly from OVF the first time and it still showed Enabled Not Accessible, I used the VAMI to unregister from vCenter, changed IP to .152, and re-registered, but then I started getting strange error messages in the VAMI.  That's ultimately why I unregistered again, deleted from disk, and redeployed again using the .153 address.

It would be nice if anyone can shed some light on what I did wrong here, or what can be done in the future to fix the Enabled Not Accessible error.  If you have any input, please post it.

[Biliana]

When you would like to uninstall VRA and deploy a new appliance, you should always follow these steps:

1) Unregister from vCenter server in the VAMI

2) Power off the appliance and then delete from disk.

This way when you deploy a new VRA, you will not get a message that there is always an appliance registered to that vCenter Server.

[ThepHuck]

Did you look at the screenshot? There was no way to unregister through the VAMI. That whole section was missing post-upgrade.

That's what concerned me.

[Biliana]

My suspicion is that before upgrade, the OVF environment of the appliance has somehow been lost. For example this may happen if you have powered on the appliance directly through the ESXi host which must be avoided, or the host on which the appliance runs has been removed and then added back to the inventory. The OVF environment is stored in the VC database and if lost the appliance cannot authenticate with its vCenter Server. If you happen to see this again, I can advise you to open a SR and provide logs for investigation.

[ThepHuck]

Nothing had changed.  I didn't touch the appliances and they were replicating VMs both directions.  The VRAs live on two different physical clusters, and they both exhibited the same behavior post-upgrade.  They're in a lab DC and have been power-cycled without graceful shutdown, but all management has been through the webclient.

[Biliana · Accepted solution]

Thanks for your reply. You said that the VRA is on a cluster, is thatcluster HA-enabled? Because in case HA needs to restart the VRA on another host, it does this through the ESX host and this might have cleared out the OVF environment. And at at the same you will still have a working configuration until you start the upgrade or try to perform any operation through VAMI configuration page. To be on the safe side, I think that before upgrade, you can do power off and then power on the appliance (simple reboot is not enough) to make sure that the OVF env is recreated.

[cougar694uV2]

The clusters do have HA enabled, this is interesting.  So before attempting any upgrades, actually power cycle the VM in vCenter, not reboot via the VAMI?

[mvalkanov]

Hi,

The power on through vCenter is crucial to populate /opt/vmware/etc/vami/ovfEnv.xml file. How the VM is powered off does not matter. resert/reboot does not help, as it does not explicitly do power on.

Regards,

Martin

[ThepHuck]

Awesome! Thanks for the info, that's very good to know!

PS,

Sorry for the response from the other account, I have too many accounts, this one had to be created for the vExpert program.