This article aims to explain how VM Instance and Host VM are related during Discovery.
Release or Environment
Cloud discovery finds resources in Amazon Web Services (AWS) and Azure clouds, and then populates the CMDB with the relevant CIs and relationships. When you discover a virtual machine in one of these cloud providers, two records are related to that virtual machine. One is called VM Instance, AWS calls it instance and Azure calls it of Virtual machine. The other record corresponds to the guest VM also referred to as Host VM or simply the OS Server.
Once a VM Instance is discovered, a record is created in the cmdb_ci_vm_instance table. When a user configures Cloud Schedule to discover these VM Instances, an option exists to automatically trigger discovery of the associated VM Host by enabling the option "Discovery VMs by IP address (Recommended)" in the Discovery Manager. When this is done, a second discovery schedule is created and will be executed AFTER cloud discovery. For example, if the Cloud Discovery schedule name is "Discover AWS", Discovery Manager creates a second schedule called "Discover- VM schedule" which will run AFTER "Discover AWS" schedule. Notice that with this configuration option no IP Ranges will exist in the "Discover- VM schedule" schedule. If user is manually creating a schedule to discover the Host VM, then IP Range must be supplied.
When both discovery schedules complete, a virtual machine will have a VM Instance (cmdb_ci_vm_instance) and a Host VM record depending on the operating system running on the virtual machine: Windows (cmdb_ci_win_server) or Linux (cmdb_ci_linux_server). Furthermore, a relationship between the VM Instance and VM Host is created in the relationship table (cmdb_rel_ci) with type "Virtualized by::Virtualizes", i.e. "Linux Server" Virtualized by::Virtualizes "Virtual Machine Instance" in the case of a Linux server. If Linux Server or Windows OS - Servers patterns is used for Discovery of the Host VM, then the "Create Relation Between Host To VM Instance" pattern post sensor script creates this relationship. Once the Host VM is created or updated in the cmdb, the business rule "Virtual Computer Check" marks this OS Server as being a virtual machine by flagging the field virtual = true.
Host VM's may not be discoverable due to the following reasons:
1. Discovered VMs doesn't have Public IPs thus no IPs inputted for IP Schedule to scan/discover.
Possible solution: Have the Public IP associated with the VM and ensure they're reachable from the MID via a simple "ping" test.
2. Public IPs are available but not reachable by the MID/MID Cluster selected
Possible solution: Check where the MID is located and if the host is reachable via a simple "ping" test
3. Public IPs available, Host is reachable to VM, but no Credentials available. The discovery status stops at the Classification stage only.
Possible solution: Ensure the credentials are created in the ServiceNow Instance.
4. Public IPs available, Host is reachable to VM, but ports aren't configured properly. The discovery status stops at the Shazzam stage only
Possible solution: Ensure the ports of the hosts are properly configured
5. Public IPs of few are considered but not others during the IP schedule
Possible solution: We do run the IP discovery only on the ACTIVE VMs i.e., Vm's state==on but not on Retired/Terminated VMs so please double-check.
Possible solution: The VM(s) are discovered in the first run and found they're retired in the subsequent runs so IP discovery isn't triggered for those kinds.