VMware

Synopsis

Trying to apply a Host profile created from another Host in a cluster today I got an error message which resulted in only some of the host profile actually being applied.

A specifed parameter was not correct. changedValue.key

 

I thought that the error message looked familiar, but couldn’t quite remember at the time, so I left what I was doing to take a look at again later. On my way home this evening I had a bit of a brainwave – the ESX host I had taken the original profile from was a slightly different update level (2) as opposed to the update level of the newer host I was applying the profile to. I also remembered where I had seen the text “changedValue.key” in the error message before – changing Advanced Settings on a Host using PowerCLI! This gave me a good idea as to where to look for the issue I was having with this Host Profile – the Advanced Settings in the Host Profile.

I knew it was probably to do with a value that was different between hosts because of their differing update levels, but to gather more information I decided to hit the log files to find out more… Opening up /var/log/vmware/hostd.log on the Host and navigating down to the time I tried to apply the Host Profile I found this (interesting bit in the screenshot below, full log text in the section after that):

[2012-02-20 19:50:07.849 F66966D0 info 'TaskManager'] Task Created : haTask-ha-host-vim.option.OptionManager.updateValues-896
[2012-02-20 19:50:07.853 F66966D0 verbose 'VersionOptionProvider'] Attempt to set readonly option
[2012-02-20 19:50:07.853 F66966D0 info 'App'] AdapterServer caught exception: vmodl.fault.InvalidArgument
[2012-02-20 19:50:07.853 F66966D0 info 'TaskManager'] Task Completed : haTask-ha-host-vim.option.OptionManager.updateValues-896 Status error
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Activation [N5Vmomi10ActivationE:0x5cf27a98] : Invoke done [updateValues] on [vim.option.OptionManager:ha-adv-options]
[2012-02-20 19:50:07.853 F66966D0 verbose 'Vmomi'] Arg changedValue:
(vim.option.OptionValue) [
   (vim.option.OptionValue) {
      dynamicType = <unset>,
      key = "Misc.HostAgentUpdateLevel",
      value = "2",
   },
   (vim.option.OptionValue) {
      dynamicType = <unset>,
      key = "Misc.HostAgentUpdateLevel",
      value = "2",
   }
]
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Throw vmodl.fault.InvalidArgument
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Result:
(vmodl.fault.InvalidArgument) {
   dynamicType = <unset>,
   faultCause = (vmodl.MethodFault) null,
   invalidProperty = "changedValue.key",
   msg = "",
}
[root@hostnamehere vmware]#

The cause:

So we can see that the Host Profile did a “change value” (changedValue) on the key “Misc.HostAgentUpdateLevel” and this is where our error was thrown with an “invalidProperty” (changedValue.key). If we google the message “vmodl.fault.InvalidArgument” we’ll arrive at the VMware SDK Reference Guide which states that “An InvalidArgument exception is thrown if the set of arguments passed to the function is not specified correctly.” In this case we’ll soon see that this is happening because the value that is trying to be changed is actually a read-only value for the Host – as it should be, as it just references the update level of the host – this wouldn’t normally be something you want to change.

The issue here was of course that original host off which the profile was based is update 2, whereas the new host having the profile applied is update 4. The two settings differ, therefore Host Profiles tries to change this value on the new Host. The setting is really read-only, therefore Host Profiles fails to apply the value and throws this error message at us, which also results in the rest of our host profile (annoyingly) not being applied. Ideally if Host Profiles found a read-only value that shouldn’t be changed, it would not change this value.

Solution:

So the simple solution is to either:

• Take a Host Profile from a Host with the settings you need which is on the same update level as the Hosts you will be applying this profile to.
• Modify this Host Profile (edit) and remove the Advanced Setting for “Misc.HostAgentUpdateLevel“.

In my case, I was testing the host profile on a clean ESX Host before using it for other Hosts – that meant I also only had one new ESX host of this particular update level and therefore couldn’t use the first option (take the profile from an existing host). So I therefore just went to Home -> Host Profiles and edited this Host Profile to get rid of the unnecessary key called “Misc.HostAgentUpdateLevel” like so:

After removing the entries referring to this read-only key, I simply re-applied the profile and this time around all the settings went on as expected and there was no more error message. So to sum it all up, check that you aren’t first of all taking a Host Profile from a reference host of a different update level as your target hosts (and if you have to you can then resort to manually editing your profile as I did). If you get cryptic errors applying your Host Profiles, check your Host log files for more info and clues as to where the issue may lie.