1 of 1 people found this helpful
Live browse the server, right click the config object and select 'Properties'
Which Configuration object type are you looking for, this should work for all of them
Assuming 8.x !
You can try and run an Upgrade Model Object on that BLPackage.
(Create a copy before you do it)
i think right now it is not easy to see what version of the CO is installed.
for the built-in COs - Unix Users, Processes, Daemons, Unix Groups, Hardware info - those are all bundled w/ the agent. when you upgrade the agent, those are upgraded. they are also part of the appserver.
the other COs - VMware, KVM, AD - those are delivered as part of the appserver only and must be distributed.
when you create a blpackage, component template and a few other object types, whatever version of the CO is present when you create that object will be used in the pacakge. so if the CO changes on a target there will be a mismatch.
so when you upgrade blade, you need to make sure to upgrade the COs on your targets and update the COs in the depot objects (w/ the Update Model Object job gerardo mentions).
First of all to check the version of CO on the agent , you do what was previously suggested (right click and properties)
Or you can go to the agent installation dir and open the ../daal/DAALRegistry.xml file and look for the CO class you wish to check its version.
As for the issue you see with your package
This is becouse there is a newer version of VMWare CO in the system
And that CO introduced a chage that auto upgrade do not know how to handle (UMO job will fail as well)
So to fix this you need to do the following:
- Distribute the newer version of CO to all your targets (agets) that work with this template (best practice is to distribute it to all targets)
- Manually remove the part which caoused this issue and add a newer version of it from a target
If you do not distribute the newer version to some targets ,to be able to work with them you will have to create a copy of this template and keep it unchanged .
Hope that was clear
The easiest way to know the version of currently distributed CO on a server is as described by Rohit (right click on root node (VMware vCenter Server for VMware CO) and select Properties).
I think you would be seeing the UMO job failure since newer version of VMware CO is imported in CO dictionary. Update Model Object job is not supported by VMware CO since there was an incompatible (non auto-upgradable) change in VMware CO where the data type of the network adapter type was changed from String to Enum to improve usability and to support additional use cases.
The process to address failed UMO job in general is described on page 46 of Release Notes of 8.1. I feel the steps to address your immediate problem are those suggested by Tal.
PS: Please make sure you create a backup/copy of your blpackage before you execute the steps
Thanks for this information.
As you said @sgokhale the UMO job failed upgrading this BLPackage. I'm going to change in the BLPackage the asset impacted by the Configuration Object change.
Regarding your proposition to run UMO job, how can we identify all jobs, templates, and BLPackages that reference a Configuration Object?
I think you can target the UMO at all jobs/packages/templates.