NAME
depot-sync-fail - chase a Sync Updates failure in vLCM after the vCenter 7.0.3c upgrade, starting with a metadata cleanup
DESCRIPTION
This error happened after we upgraded to vCenter 7.0.3c when selecting the ‘Sync Updates’ feature within vLCM.
It got stuck at 10% for a long time after which it jumps to 90% all of a sudden and in the end failing with the following error:
The first option I tried was to run a cleanup script to get rid of old metadata. You need to download a cleanupscript and run it on the vcsa server. As described in the following kb article.
root@vcsa [ /tmp ]# ./cleanup_patch_store.sh delete from vci_platform_metadata where metadata_id in (28,2,3,4,5,1,11,12,13,14,17,31,32,33,34,34,21,22,23,24,25,27,30,8,18,19,20,35,26,9,10,29,15,6,46,47,51,52,53,54,55,55,37,45,40,41,42,43,44,48,49,50,39,38,16,56,7,36) delete from vci_metadata_files where id in 28,2,3,4,5,1,11,12,13,14,17,31,32,33,34,34,21,22,23,24,25,27,30,8,18,19,20,35,26,9,10,29,15,6,46,47,51,52,53,54,55,55,37,45,40,41,42,43,44,48,49,50,39,38,16,56,7,36) Cleanup: /storage/updatemgr/patch-store/hostupdate/HPE/micro-depot__metadata-esxi6.7uX-mgmt-bundle-3.3.5-1__index.xml Cleanup: /storage/updatemgr/patch-store/hostupdate/micro-depot__vendor-HPE__metadata-hpe-esxi-drv-bundles-670.U3.10.6.0__index.xml Cleanup: /storage/updatemgr/patch-store/hostupdate/micro-depot__vendor-HPE__metadata-hpe-HPUtil-esxi6.5-bundle-2.6a-1__index.xml Cleanup: /storage/updatemgr/patch-store/hostupdate/HPE/micro-depot__HPE-ESXi-7.0-Addon-cumulative_metadata__index.xml Cleanup: /storage/updatemgr/patch-store/hostupdate/micro-depot__vendor-HPE__metadata-esxi6.7-util-bundle-3.3.0-9__index.xml Cleanup: /storage/updatemgr/patch-store/hostupdate/HPE/metadata-hpe-esxi-drv-bundles-600.10.2.0.zip Cleanup: /storage/updatemgr/patch-store/hostupdate/micro-depot__vendor-HPE__metadata-hpe-esxi-drv-bundles-670.U3.10.4.5__index.xml Cleanup: /storage/updatemgr/patch-store/hostupdate/micro-depot__vendor-HPE__metadata-hpe-esxi-drv-bundles-670.U3.10.7.0__index.xml Etc…
Unfortunately that didn’t solve the problem so I started to investigate further. There was a possibility that the hostupdate20-consolidated-index.xml was corrupted so I renamed it so that a new version would be created after you select ‘Sync Update’ again.
root@vcsa [ /storage/updatemgr/patch-store/hostupdate ]# mv /storage/updatemgr/patch-store/hostupdate/hostupdate20-consolidated-index.xml /storage/updatemgr/patch-store/hostupdate/hostupdate20-consolidated-index.xml.bak
But this didn’t do the trick also and I had one more option left and that was to reset the “db”. As described in the following kb article. Make sure to make a snapshot of the appliance before you proceed.
service-control –stop vmware-updatemgr
/usr/lib/vmware-updatemgr/bin/updatemgr-utility.py reset-db
rm -rf /storage/updatemgr/patch-store/*
service-control –start vmware-updatemgr
root@vcsa [ ~ ]# service-control --stop vmware-updatemgr Operation not cancellable. Please wait for it to finish... Performing stop operation on service updatemgr... Successfully stopped service updatemgr root@vcsa [ ~ ]# /usr/lib/vmware-updatemgr/bin/updatemgr-utility.py reset-db Resetting vSphere Update Manager database... Successfully reset vSphere Update Manager database Start vSphere Update Manager service to apply the setting. root@vcsa [ ~ ]# rm -rf /storage/updatemgr/patch-store/* root@vcsa [ ~ ]# service-control --start vmware-updatemgr Operation not cancellable. Please wait for it to finish... Performing start operation on service updatemgr... Successfully started service updatemgr
And now, after selecting Sync Update it completed successfully.
SEE ALSO
hostprofile-vs-config(8), vmdk-lock(8), vcf-study-guide(8), vmware(7)