Determine VM Hardware version and Host version

[BWinchell]

I am working on a workflow that will upgrade VM hardware version and/or vmtools as needed.  The one problem I have run into is the a decision question:

"Does this VM require hardware upgrade?"  (sounds relatively simple )

3 parts are required to make this decision:

     1) What version is currently running on the VM? > This is covered by the attached workflow.

     2) What host machine is the VM currently running on? > This is covered by the attached workflow.

     3) What VM hardware version is supported by the host? > cannot figure this one out.

I figure if there is not a striaght answer for this like an object I can query, then the next thought is at least what version of ESXi is running.  Then I can embed in the code ESXi4.1 = VMversion7  |  ESXi5.0 = VMversion8 (something like this).

Once the 3rd part is acquired, then the decision process is simple.  I could hard code the "host supported option" but that does not help in a mixed ESXi environment (we run different clusters at different levels of ESXi 4.1 or 5).

Any help will be good.

Thanks

B

[tschoergez]

Hi!

have you tried ONYX to figure out?

maybe even vSphere client does the check before upgrade...

Also: try to search for "supported" in the API reference, maybe there is an Property of the Host/VM for supported HW versions...

Regards,

Joerg

[BWinchell]

I have tried to use Onyx but not helpful for this.  There must be a switch/varible somewhere on the host that tells the system version (VM hardware & VMtools).  I need to be able to dig into those options to find what I am looking for.

Thanks

B

[StefanBerner]

I don´t know if you already figured out?

You can read the HW-version in the following way:

vm.config.version contains a string woith the hw version vmx-*

Stefan

[BWinchell]

Hi Stefan,

That code will only provide what version the VM is running at.  The code I actually use for that is:

// Retrieve the environment browser for the VM
var envBrowserRef = vm.environmentBrowser;
var envBrowser= VcPlugin.convertToVimManagedObject(vm , envBrowserRef);

// Debug output
if (debugOutput == true) {
    System.log("envBrowserRef variable: '" + envBrowserRef + "'");
    System.log("envBrowser variable: '" + envBrowser + "'");
    }

// Invoke the queryConfigOption API which returns VirtualMachineConfigOption
var vmConfigOption = envBrowser.queryConfigOption();

//Debug output
if (debugOutput == true) {
    System.log("vmConfigOption variable: '" + vmConfigOption + "'");
    }

// Retrieve the hardware version from the VirtualMachineConfigOption
var vmHWversion = vmConfigOption.hardwareOptions.hwVersion;
System.log("The Hardware Vesrion for VM " + vm.name + " is: " + vmHWversion);

The thing I would like to do is now compare that to what the host machine can support (ver4,7,8...) and have a workflow decision decide if the VM can be upgraded.  Currently I have hard coded the host capabilities to compare but would prefer that to be dynamically determined based on the revision of the host.

Thanks

B

[Burke-]

As of this reply, this thread is in the Orchestrator Plug-in SDK community. Please move it to the "Orchestrator" community.

Thank you.

[tschoergez]

moved to "Orchestrator".

[jauling]

Hi, sorry to reply to a very old thread, but I came across this while trying to do something similar.

We've got a bunch of VM  templates that all may have different hardware versions. We provision all our VMs from one of these vm templates, and I've added in the provisioning workflow a step to upgrade the VM hardware, just to keep things current. I had inserted the built-in workflow that ships with vRO 7.2 called Upgrade VM Hardware (force if required), but I had no idea it would error out if the hardware version was already up-to-date. Am I the only one who thinks that's a bit silly? If anything, I'd think a warning or just an info message would be sufficient.

Error in (Dynamic Script Module name : WaitTaskEndOrVMQuestion#27) Task 'UpgradeVM_Task' error: Virtual machine compatibility is already up-to-date.

I looked into writing the logic to determine if a hardware version upgrade is necessary, but I also ran into the problem of how to determine what hardware version a host can support. Sure, I could probably create my own lookup table that maps ESXi version to hardware version, but that seems like too much work and maintainence. I'm no vCO/vRO expert, but it seems by just blindly mapping the workflow error path to the same as the success path can solve my problem.

I realize this is foolish, considering that means it will continue on all errors. Does anyone else have a suggestion? BWinchell​ or maybe bwinchell2​ did you ever find a solution?

[bwinchell2]

jauling​

I have not looked at this in the few years and the quick answer is no (dropped the ball).  I never got back to this workflow to make it better.

There is a workflow called "TNG_UpgradeVmhardwareArray".  Within that, a general attrib called "vmHWversion_latest".  This is currently hardcoded.  You can easily move this to be an input attrib and that way you can set the highest virtual hardware code every time it runs.

Not ideal, but the best at current.

If I get time over the weekend, I will circle back to these workflows and try to fix this shortcoming.

Thanks

B

[iiliev]

Here is a code showing how to enumerate supported HW versions by a host (input variable host of type VC:HostSystem)

var cods = host.parent.environmentBrowser.queryConfigOptionDescriptor();
for each (var cod in cods) {
  // check VcVirtualMachineConfigOptionDescriptor documentation
  var s = "HWVersion: " + cod.key;
  if (cod.defaultConfigOption) s += " [default]";
  if (cod.createSupported) s += " [create]";
  if (cod.runSupported) s += " [run]";
  if (cod.upgradeSupported) s += " [upgrade]";
  System.log(s);
}

This code will dump all HW version supported by the host. Depending on your other code, you may need to add some additional code to convert version to number (eg. from vmx-10 to 10), or to determine which one of them is the largest version (usually it is the last one in the list), or which one is the default.

[bwinchell2]

llian​

Thanks for that code.  That will help out a lot to revamp this workflow.  I will inject that and render some use cases on how to determine the VMtools value we want to upgrade.

B

[bwinchell2]

jauling​

I have updated the workflows, actions, logging, logic, etc....

I think these work better than the original.  You have options now to upgrade your VMhardware to the default level of the ESXi the VM currently runs on or override it with a specific VMhardware level.

llian​

Again, thanks for the code snippet as that saved me a bunch of time trying to figure that portion out.

Thanks

B