FAQ - Overview of Virtual Machine Instance objects and Virtual Machine objects and the associated CIs

Synopsis and Purpose

CI Sync can read from virtualisation platforms (including cloud providers) and from OS level discovery products so that customers can sync the various virtualisation objects into their ServiceNow CMDB. Two of the key object types are Virtual Machine Instances and Virtual Machines (VMs). The scope of this FAQ is solely about those two object types (VM Instances vs VMS).

Not only does CI Sync create specific CIs for VM Instances and VMs (i.e. creates CIs in the specifically intended CMDB CI Tables/Classes intended for those objects), CI Sync also attempts to create relationships (sometimes called dependencies) between the CIs. Attempts is highlighted because CI Sync’s ability to create relationships between VM Instances and VMs depends on several key factors:

1. Does the CMDB contain both sets of CIs (i.e. are there a full suite of CIs for both VM Instances and VMs)? CI Sync can’t create a relationship between the two CIs unless both of the CIs exist (this includes CIs that may have been created manually or from another ingestion source other than CI Sync).

2. Do each of the CIs contain sufficient attribute values to allow CI Sync to match the two different CIs to one another? CI Sync attempts to match from VM Instances to the VMs, and CI Sync uses attributes like Serial Number, MAC Address/s and Name when attempting to find a matching VM. If there is insufficient data in these attributes, CI Sync won’t be able to match the CIs and won’t be able to create a CI-to-CI relationship record in the CMDB.

This purpose of this FAQ is two-fold as follows

1. To explain the overall topic in more detail so customers have a strong understanding of how the data behaves in the CMDB.

2. To assist customers diagnosis the reason why CI-to-CI relationships are not being created as expected (if that occurs).

Overview of the Objects

CI Sync has connectors for various virtualisation platforms such as VMware and Nutanix. CI Sync also has connectors for the major cloud providers such as Azure, AWS and GCP. These platforms and cloud providers deliver virtualisation of compute resources, and they all present an object type commonly called a VM Instance. A VM Instance is not the same as VM itself.

CI Sync also has connectors for various discovery products such as Lansweeper, SCCM, etc and discovery “bi-product” solutions such as Defender for Endpoint, InTune, etc. These products interrogate running compute workloads at the OS level using protocols such as WMI for Windows servers/computers and SSH for Linux servers/computers. If a discovered computer/server runs on a virtualisation platform (e.g. Nutanix, VMware), or is running in the cloud (e.g. in Azure, AWS, GCP), then the object type is of course called a VM.

In summary

1. Information about VM Instances is read from a hypervisor (or cloud provider). The hypervisor provide a kind of “top down” view of the virtual resource.

2. Information about VMs is read from a discovery source that has queried the operating system using protocols like WMI or SSH. These protocols provide a kind of “bottom up” view of the virtual resource.

As a result, CI Sync elicits two different object types when reading from the products/providers noted above. The two different objects are closely related to one another, but they are entirely different in the way ServiceNow expects them to be stored and used.

What is a Virtual Machine Instance?

• A VM Instance is an object that represents the presence or existance of a Virtual Machine (VM).

• A VM Instance object does NOT represent the running Operation System itself (or what runs on and inside the VM Operating System).

• A VM Instance contains attributes and related records like the following:

  • The physical host (e.g. the ESX Host) on which the Virtual Machine Instance has been allocated.

  • Running State (is the instance On or Off).

  • The quantity of CPU/s allocated to the instance (i.e. allocated by the hypervisor).

  • The quantity and size of disks allocated to the instance (i.e. allocated by the hypervisor).

  • The Virtual Network Interface Cards (vNICs) allocated to the instance.

What is a Virtual Machine (VM)?

• A VM is an object that represents the computer/server itself. That is, an object that represents the running OS and what has been allocated to, and installed upon, that running OS. A good example is Windows Server VM or a Linux Server VM.

• A VM contains attributes and related records like the following:

  • The OS name and version the VM is running.

  • The installed software on the VM.

  • The patches applied to the OS and software on the VM.

  • The services or processes running on the VM.

  • And so on.. everything we commonly expect can be interogated from protocols like WMI and SSH.

Frequently Asked Questions about this Topic

How does ServiceNow treat Virtual Machine Instances vs Virtual Machines within the CMDB?

The ServiceNow CMDB design deals with VM Instances and VMs differently.

See the table below which shows the default CMDB Class (table) where ServiceNow expects these CIs to be stored.

How does CI Sync establish CI-to-CI Relationships (dependencies) between Virtual Machine Instance CIs and Virtual Machine CIs in the CMDB?

CI Sync wil attempt to establish a relationship (dependency) between Virtual Machine Instance CIs and Virtual Machine CIs. Here’s how it works:

• When CI Sync processes VM Instance records (from VMware, Nutanix, Azure, AWS, GCP, etc) CI Sync tries to match an existing VM in the cmdb_ci_computer table (or deritive tables) using attributes available on the VM Instance record.

• Typical attributes used for matching can include Serial Number, MAC Address/s, Hostname/Name.

• The attributes available to perform the match depends on the source system where the VM Instance record originates from. For example, GCP only provies a hostname, but VMware and Nutanix provides multiple attributes that CI Sync can use to attempt a match.

When CI Sync is able to match a VM Instance CI to a corresponding VM CI, an “instantiates” relationship type is created. This table shows the relationship types created for each virtualisation source system.

^#1 In the Azure Portal, Virtual Machine Instances are shown/labelled simply as “Virtual Machines” (which can further confuse this entire topic).

What can customers do to reduce the likelihood of CI Sync jobs not creating the intended CI-to-CI Relationships

These are the best practice recommendations for this topic:

1. Run the CI Sync job/s that processes the VM Instances before the running the CI Sync job/s that process the VMs (i.e. run sync jobs from virtualisation products or cloud providers before running sync jobs from discovery products like Lansweeper, SCCM and so on).

2. Make sure there is sufficient attribute/value coverage on attributues such as Serial Number, MAC Address/s and Name on both the VM Instance CIs and the VM CIs. This is unlikely to be an issue when CI Sync is used to sync both sets of objects/CIs. Instead, this may be an issue if CI Sync is being used with one set of objects (e.g. VM Instance CIs only), and another source, including manual data entry, is being used to create VM CIs in the CMDB.

Troubleshooting and Advanced Diagnosis

How will customers know if CI Sync can’t find a match between Virtual Machine Instance CIs and Virtual Machine CIs?

CI Sync will report “ignored” results when CI Sync cannot create a relationship between VM Instance CIs and corresponding VM CIs. Customers will notice the ignored results in the job log of a sync job from one of the virtualisation products or cloud provider data source.

The screen shot below is from an AWS sync job log showing many ignored results when CI Sync tried to create CI-to-CI relationships for “EC2 Instance instantiates Computer”.

How can customers diagnose the underlying cause of CI Sync not matching Virtual Machine Instance CIs and Virtual Machine CIs?

Customers can perform self-diagnosis on this topic before contacting Syncfish.

1. Login to your CI Sync SaaS instance (so you can use the CI Sync Web UI).

2. Navigate to the Settings page and scroll down to the Destination Connections section.

3. Locate the connection related to the ServiceNow instance you are using for this diagnosis, and click the Update link.
   

   

4. Scroll down and locate the Additional Settings Heading and locate the Connection Setting called “JSONATA Debugging” and do the following:

   1. Tick the “Overwrite Default” checkbox.

   2. Enable the slider to “On”, and then scroll to the bottom of the page and click the “Save Connection” button.
      

      

      
      

   3. Additional Notes:

      1. The heading will say “Test Environment” vs “Prod Environment” depending on whether the particular ServiceNow connection has been tagged by you as “TEST” or “PROD”.

      2. For more information about this specific CI Sync Connection Setting visit this page: Logging and Debugging
         

5. Run a new CI Sync job after enabling this setting (to increase the logging detail).

6. Once the job completes

   1. Navigate to the job log

   2. Locate the progress indicator showing the ignored results

   3. Click the progress indicator bar to jump to the individual task log entries.

   4. View the detailed information about the ignored task by clicking one of the ignored tasks.

   5. Review the “Response Message” details to understand the match query performed by CI Sync, including the CI name attempting to be matched.

Related Articles

1. The Logging and Debugging Connection Setting

2. Rule 2 - AWS CI-to-CI Relationships

3. Rule 2 - Azure CI-to-CI Relationships

4. Rule 2 - GCP CI-to-CI Relationships

5. Rule 2 - Lansweeper On-Prem CI-to-CI Relationships

6. Rule 2 - Lansweeper Cloud CI-to-CI Relationships

7. Rule 2 - Nutanix CI-to-CI Relationships

8. Rule 2 - VMware CI-to-CI Relationships

Control Information