I had the pleasure of upgrading three PernixData installations today from 2.5.0.8 release to 3.1. Before I started I wanted to do a backup, however according to the upgrade guide, all accelerated VMs must be using Write-Through mode during the upgrade process. So before creating a backup, I went ahead and documented VMs current FVP configuration (Write-Through or Write-back incl. peer information) and configured all accelerated VMs to use Write Through mode.

You could start doing a backup of the database, but when you thereafter change the VMs FVP configuration, you would end up with a conflict if you need to rollback the database. So this is the reason I do the backup after I changed the VMs acceleration policy.  However, you could do both.

After doing the mandatory backup of databases and snapshot of the FVP Management servers I went ahead and made two other safeguards, as I have earlier seen issues with database connectivity.

On the Pernixdata FVP management server I created a backup of the following files

  1. Hibernate.cfg.xml              (as this contains information about database connectivity)
  2. Prnxms.config                     (general Pernixdata config file)

To summarize the upgrade procedure in high-level this is my recommended method:

  1. Document VMs acceleration policies and if using Write-back – remember to document the Write Replication settings as well (peer hosts in same or different fault domain)
  2. Configure all accelerated VMs to use Write Through mode during the upgrade process
  3. Wait for the status columns to verify all VMs are in Write Through mode. This could take a while as it need to destage data to permanent backend storage.
  4. Shutdown the FVP Management Server
  5. Backup the database and snapshot the FVP Management Server
  6. Power on the FVP Management Server and verify its working
  7. Create a backup of the two files mentioned above (hibernate.cfg.xml and prnxms.config)
  8. Prepare VMware Update Manager by importing the VUM Pernixdata Host Extension and create a baseline for this.
  9. Upgrade the PernixData FVP Management Server
  10. Verify that its working! (I always check the log files)
  11. Upgrade the host extension module using VMware Update Manager.
  12. Reconfigure the VMs back to their original accelerated policy

So I actually ran into problems after the upgrade of the FVP Management server component, as it was not working. I checked the log file and found this error message:

 2015-12-29 09:14:18,671 [pool-1-thread-1] ERROR DBHelper – Failed to connect to database

org.hibernate.exception.GenericJDBCException: Could not open connection

As you can see above, I ran into a database connectivity issue as I foresee I would. You get the hint here to look in the hibernate file as well. When comparing the backup hibernate.cfg.xml file with the running version I found the following differences:

Before upgrade:

<property name=”hibernate.connection.url”>jdbc:sqlserver://databaseserverfqdn;databaseName=prnx;integratedSecurity=true;portnumber=5740</property>

After upgrade:

<property name=”hibernate.connection.url”>jdbc:sqlserver:// databaseserverfqdn,5740;databaseName=prnx;integratedSecurity=true</property>

Changing this back to use the syntax from the backup file and restart the FVP Management Server service – fixes the problem.

After this the rest of the upgrade went perfectly fine without any issues and the customer is now running on FVP 3.1.

Now that you upgraded go ahead and use your 30-day free PernixData Architect and see all the awesome data about your infrastructure and data usage. Launch the new Pernixdata UI console at port 60002. Go to the PernixData Hub à Licensing à PernixData Architect à Click on the vCenter Server and Start Trial.