RecoverPoint for Virtual Machines: Non-Disruptive Upgrade Failing at on 0% with Status 400


   Article Number:     535262                                   Article Version: 3     Article Type:    Break Fix 




RecoverPoint for Virtual Machines 5.2,RecoverPoint for Virtual Machines 5.2 P1,RecoverPoint for Virtual Machines 5.2 P2,RecoverPoint for Virtual Machines 5.2 P3,RecoverPoint for Virtual Machines 5.2 P4,RecoverPoint for Virtual Machines 5.2 P5





When attempting to upgrade a RecoverPoint for Virtual Machines, RP4VMs, environment, the RP4VMs Deployer fails on the first virtual RecoverPoint Appliance at 0% with an error: Status 400.       
        The pre-checks for Deployer all pass without incident or problem and the upgrade officially commences before the 0% failure status appears.

                            In Cluster Logic Logs of RPA1:                   
          2018/07/02 09:14:09.583 [http-bio-443-exec-5] ( ERROR - VerifyClusterNotAlreadyUpgradedTask :Task failed with unexpected exception type: VERIFY_CLUSTER_NOT_ALREADY_UPGRADED java.lang.NullPointerException at com.emc.recoverpoint.deployment.logic.VerifyClusterNotAlreadyUpgradedTask.createAndAddSubTasks(
      In Cluster Logic Logs of RPA2:     
      2018/07/02 08:52:02.996 [http-bio-443-exec-5] ( DEBUG - upgradeCluster - going to call to RPA1 for upgradeCluster   








      The bottom log print witnessed on RPA2 is the call looking for vRPA1 as site control.  When this instance occurs, it is because vRPA1 was not listed as site control.     
      In order to determine which RPA has site control, log into one of the RPAs using the LAN IP using an SSH application such as PUTTY.  In 5.2x, log in with the user name of admin.     
      From the list of menu options, select the following:     
      [2] Setup     
      [6] View settings     
      [1 -5] Choose the cluster you are upgrading     
      The list of IPs and other data should be displayed for that cluster.  Towards the top you will see the cluster IP.     
      Once you have this IP, log into it as well using the same SSH application using the admin user name.       
      At the bottom of the screen, it should state which RPA owns the site control IP.      
      If it is RPA1, you are clear to proceed without intervention.     
      If it is RPA2, reboot the RPA to move site control over to RPA1.   








      Ensuring that vRPA1 has site control will ensure this situation is not encountered in the future.  To ensure vRPA1 has site control, log into the site control IP using an SSH client and confirm which vRPA is listed as owning the site control IP.  If the vRPA listed does not show vRPA1, please reboot the site control vRPA, forcing site control over to vRPA1.     
      Once this has been completed, the RP4VMs Deployer can be retried once again.     
      This issue is addressed in the RecoverPoint for Virtual Machines version 5.2.1.   


      To determine whether an upgrade is appropriate for your environment, contact the Dell EMC Customer Support Center or your service representative and reference this solution ID.