Fixing the UsageMeter 4.3 to 4.5 upgrade issues

Recently we had to upgrade a couple of our VMware Usage Meter environments. VMware Usage Meter is a tool that monitors all VMware based software solutions on the licences they are using. These numbers are used to report your license usage to your aggregator. This piece of software is mostly used by VMware Cloud Providers. Multiple different versions were present starting from 4.2, 4.3 and even 4.4. All of these had to be upgraded to 4.5 because of License Compliancy reasons. VMware asks the cloud providers to be up to date in regard to the UsageMeter versions.

The process to upgrade is actually really easy nowaways, and especially since UsageMeter 4.5. The upgrade consists out of more or less the following couple of commands:

root@mgmt [ ~ ]# mkdir /root/upgrade
root@mgmt [ ~ ]# mount -o loop /dev/cdrom /root/upgrade
root@mgmt [ ~ ]# bash /root/upgrade/upgrade-um.sh
Has a snapshot of the vCloud Usage Meter appliance VM been created on the vCenter Server environment that it's running on? (y/n): y

This worked flawlessly on all environments except one, the UsageMeter 4.3 version. Usually once the upgrade completes it will mention the following line on the terminal or in the upgrade log which can be found here: /opt/vmware/var/log/um-upgrade.log

libgcrypt x86_64 1.8.8-1.ph3 photon-umError verifying signature of: /var/cache/tdnf/photon-um-iso/rpms/vmware-studio-init_3.0.0.7-200511111706.noarch.rpm Error processing package: vmware-studio-init_3.0.0.7-200511111706.noarch.rpm 
Error(1512) : RPM not signed. Use --skipsignature or --nogpgcheck to ignore. -iso   1.20M 1253355

Error(1011) : No matching packages
Upgrade fail while installing vmware-um-agent!

It seems that some RPM’s were not signed correctly, eventhough the same ISO worked without any issues on the other environments. I tried manually installing the RPM with the following command: rpm --install xxxxxx.rpm. That did work, but running the upgrade script again another RPM failed to install because it was not signed. So that wasn’t an option.

I found some older KB’s that were not really that relevant to my issue, but they stated that we should clean the cache for the Photon OS packages from the package manager. This can be done by executing the following command:

root@mgmt[ ~ ]# tdnf clean all
Refreshing metadata for: 'VMware Photon Extras 3.0 (x86_64)'
Refreshing metadata for: 'VMware Photon Linux 3.0 (x86_64)'
Refreshing metadata for: 'VMware Photon Linux 3.0 (x86_64) Updates'
Cleaning repos: photon-updates photon photon-extras0%
Cleaning up everything

After this it still didn’t work. After this I created a VMware case and after a while I got a confirmation back that the package which was giving the issue, vmware-studio-init* was actually a dependency package, which is why the install option didn’t work which I tried earlier. We were asked to upgrade the package manually by using the following command:

rpm -U /root/upgrade/package-pool/vmware-studio-init_3.0.0.7-200511111706.noarch.rpm --noverify

You should do this once the ISO is mounted within the GuestOS, which by the way works as such (You can also find it HERE):

Create an update director: mkdir /root/upgrade
Mount the ISO: mount -o loop /dev/cdrom /root/upgrade

After I did this the update still didn’t go through, I also had to manually upgrade the following package:

rpm -U vmware-studio-appliance-config_3.0.0.7-200511111706.noarch.rpm --noverify

Now we were able to continue the upgrade procedure (which is started with bash /root/upgrade/upgrade-um.sh. After this we were able to view the beautiful upgrade completion:

====================================================================

    Appliance upgraded to version 4.5.0.0

    Please find upgrade log file in the location /opt/vmware/var/log/um-upgrade.log


====================================================================

There you have it! The UsageMeter upgrade for 4.3 to 4.5 wasn’t that easy and straight forward as any other version. Fortunately this was easy to fix and now you guys should be able to fix it yourselfes. I asked VMware to include this in a fix or in their documentation, since the upgrade documentation does not state any of these issues.