Virtual Machine State Change Variance

[Ken K1]

During testing I noticed that the cmdb_ci_vm_instance and cmdb_ci_vmware_instance rules for handling state changes are different.   I'm on Tokyo (patch4a).

Example:

vm_instance (virtual machine in azure or aws)

When a state change moves to Terminated the operational status moves to Non-Operational and Install Status as Absent

vmware_instance (virtual machine on esx)

What a state changes moves to Terminated the operational status stays on Operational and Install Status moves to Retired.  

Can someone explain the variance for these two tables?   I would think any object that is Terminated would be Retired and Retired.

[Ratnakar7 · Accepted solution]

Hi @Ken K1 ,

The variance you observed in the handling of state changes between cmdb_ci_vm_instance and cmdb_ci_vmware_instance tables is due to the different configurations and workflows associated with virtual machines running in different environments.

The cmdb_ci_vm_instance table is specific to virtual machines running in cloud environments such as Azure or AWS. In these environments, when a virtual machine is terminated, it is considered non-operational, and the install status is set to Absent. This aligns with the understanding that the virtual machine instance is no longer active and available.

On the other hand, the cmdb_ci_vmware_instance table is specific to virtual machines running on ESX servers. In this context, when a virtual machine is terminated, it is still considered operational, but its install status is set to Retired. This reflects the fact that the virtual machine may still exist in the virtualization environment but is no longer actively used or supported.

The variance in handling state changes between these two tables is driven by the different behaviors and conventions of the underlying virtualization platforms (cloud vs. on-premises ESX servers) and the specific workflows and configurations defined in ServiceNow for each table.

It's important to note that these variations are specific to the ServiceNow platform and its configurations. In other contexts or systems, the terminology and handling of state changes may differ.

Thanks,

Ratnakar

[Ken K1]

This makes sense and aligns to some research I have done independently.   I sincerely appreciate the feedback and explanation.