ITOM discovery

priyaadhikarla
Tera Contributor

Sunday

We’re encountering a situation where certain servers are incorrectly marked as “retired” in discovery tools due to terminated VM instance relations. However, these VMs are still active and running in production. This appears to stem from a prior migration activity, after which the VM status remained “terminated,” causing the operational status to reflect “retired.”

We’ve raised a HI case and were informed that this is expected out-of-box behavior—once a VM instance is marked terminated, it cannot be automatically updated back to “up.”

 

 

  • Is this behavior standard and meant to be managed manually?

  • Has anyone implemented a technical workaround or automation to restore accurate operational status in such scenarios?

 

0 Helpfuls
  • 89 Views
2 REPLIES 2

Fabian Kunzke
Mega Sage

20 hours ago - last edited 20 hours ago

Hey,

 

This is indeed standard behavior, but it is not meant to be managed manually. To understand where this status comes from, feel free to take a look here: https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/discovery/refere...

 

Outside of that, the logic is, that terminated instances are retired for good (hence why it is a separate state from "just" retired). They are not meant to go back to a running state. To correct this, i'd propose you update all impacted instances once to be in the correct state. From then on onwards, the automation through the VM discovery/events should work correctly again.

 

This should not be a reoccurring issue - at least from my experience.

 

On a side note: I find the documentation here a bit irritating, as it leads to believe that "terminated" instances are indeed allowed to go back into a running state - which seems unreasonable.

 

Hope this helps,

Regards

Fabian

0 Helpfuls

SagnicDas_dev
Mega Guru

19 hours ago

Hi @priyaadhikarla ,

Yes, this is standard out-of-box (OOB) behavior in ServiceNow Discovery . Once a VM instance state is set to "Terminated" by a cloud provider or vCenter event, the platform's logic typically prevents it from automatically reverting to "on" or "off" because termination is considered a final lifecycle state. 
The issue often persists because Discovery schedules for the underlying server (e.g., Windows or Linux patterns) may not trigger if the associated VM Instance CI is marked as Retired, effectively orphaning the server record. 
 
Recommended Solutions and Workarounds : 
1. Use a Scheduled Job for Bulk Recovery :
If this issue stems from a one-time migration event, a script can be run to "force" the recovery of these CIs. This is the most common technical workaround. 
  • Logic: Identify records where the VM Instance state=terminated but the associated Server CI was recently updated by an IP-based Discovery or is known to be active.
  • Script :
     
    var gr = new GlideRecord('cmdb_ci_vm_instance');
gr.addEncodedQuery('state=terminated^install_status=3'); // '3' is typically 'Retired'
// Add your logic to filter by your specific migration datagr.query();while (gr.next()) {
    gr.state = 'on'; // Or 'off' based on your requirement    gr.install_status = 1; // Set to 'Installed'    gr.operational_status = 1; // Set to 'Operational'    gr.update();
}
    Use code with caution.
2. Implement a "Discovery Source" Reconciliation Rule
You can use the Identification and Reconciliation Engine (IRE) to prevent the "Retired" status from being locked. Create a Reconciliation Rule that allows your specific IP-based discovery to overwrite the status set by the Cloud/vCenter event-driven discovery. 
 
3. Adjust Pattern Post-Sensor Scripts :
For a more permanent automation, customize the post-sensor script of your cloud patterns (e.g., "Amazon AWS - Virtual Server").
  • Modify the script to check if a "Terminated" VM instance actually still exists in the provider's response during a full horizontal discovery.
  • If the VM is found during a full scan, force the state field to update regardless of its previous value. 
 
4. Verification with Cloud Operations Workspace :
In 2026, use the Cloud Operations Workspace to review "Stale CIs". If the VM is still active in production, it should appear as a "discrepancy" between the Cloud Inventory and the CMDB, allowing you to remediate it directly from the workspace. 
Would you like a more detailed script to identify exactly which CIs are currently "terminated" but still have an active server relationship ?

If you find it helpful please mark it as helpful.

Regards,

Sagnic