How Discovery Creates the Virtualized by::Virtualizes Relationship for AWS and Azure ServersSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This article explains how Discovery identifies servers running on AWS and Azure, marks them as virtual, and creates the Virtualized by::Virtualizes relationship to their cloud VM instance. The process runs in two layers: Layer 1 — Pattern: Runs during Discovery. Detects whether the server is on AWS or Azure. Sets virtual = true on the CI and captures the cloud instance identifier into object_id. Layer 2 — Post Sensor: Fires after the Identification Engine processes the payload. Reads object_id and manufacturer from the CI, finds the matching cmdb_ci_vm_instance record, and creates the relationship. Note: Both layers must succeed. If the pattern does not populate object_id, the post sensor exits immediately. If the VM instance record does not exist in the CMDB, the post sensor finds nothing to link to. Pattern: Windows OS - Servers, Linux Server Post Sensor: Create Relation Between Host To VM Instance Execution ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Layer 1 — What the Pattern Does The pattern must set two fields on the CI. Without both, the post sensor cannot run correctly. virtual = true — Marks the CI as a virtual machine in the CMDB. object_id — The cloud platform's unique instance identifier. The post sensor uses this to find the matching VM instance record. If null — post sensor exits and no relationship is created. Windows — AWS and Azure virtual = true is set when either isAzure = true OR isEc2 = true. One condition is sufficient. object_id conditions by platform: AWS — Requires shouldDiscoverAmazon = true AND isEc2 = true AND awsData[*].instance_id not empty. Value stored: awsData[1].instance_id Azure — Requires isAzure = true AND uuidSerial not empty AND shouldDiscoverAzure = true. Value stored: uuidSerial (endian-converted if SMBIOS ≤ 2.5) Linux — AWS Both virtual = true and object_id require ALL of the following: shouldDiscoverAmazon = true isEc2 = true awsData not empty Value stored: awsData[1].instance_id Linux — Azure Both virtual = true and object_id require ALL of the following: uuidSerial not empty isAzure = true shouldDiscoverAzure = true Value stored: UUID from dmidecode (endian-converted if SMBIOS ≤ 2.5) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Layer 2 — The Post Sensor After the pattern completes and the Identification Engine processes the payload, the post sensor fires. This is where Virtualized by::Virtualizes gets created. Steps run in order: Step 1 — Find the computer CI: Iterates through payload items. Looks for a CI class that extends cmdb_ci_computer. Loads the GlideRecord as computerGlideRecord. Step 2 — object_id check: Reads object_id from the computer CI. If null — exits immediately. No relationship is created. Step 3 — Manufacturer gate: Reads manufacturer from the CI. Must contain "microsoft", "amazon", or "xen" (case-insensitive). Any other value — exits immediately. Step 4 — Find matching VM Instance: Azure (manufacturer contains "microsoft"): Calls getServerUuidSerialNumber() to retrieve uuid_serial_number from cmdb_serial_number. Queries cmdb_ci_vm_instance WHERE vm_inst_id IN [object_id, uuid_serial_number]. AWS / Xen (manufacturer contains "amazon" or "xen"): Queries cmdb_ci_vm_instance WHERE object_id = object_id directly. Step 5 — Handle multiple results: Skips instances where state = "terminated" — unless it is the only record, in which case it is used as a last resort. Picks the first non-terminated instance. Step 6 — Clean up stale relationships: Queries cmdb_rel_ci for existing Virtualized by::Virtualizes relationships on this server where the child is not the resolved VM instance. Deletes all of them before creating the correct one. Step 7 — Create the relationship: Calls createRelationIfNotExist(). If the relationship already exists — nothing is written. If not, inserts a new record into cmdb_rel_ci. Parent: Server CI (cmdb_ci_win_server or cmdb_ci_linux_server) Child: VM Instance (cmdb_ci_vm_instance) Relationship type sys_id: d93304fb0a0a0b78006081a72ef08444 (hardcoded) Step 8 — correlation_id sync: Compares correlation_id on the computer CI to object_id on the resolved VM instance. If they differ, updates correlation_id on the computer record. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Key Tables cmdb_ci_win_server / cmdb_ci_linux_server — The discovered server CI. Pattern sets virtual and object_id here. cmdb_ci_vm_instance — The cloud VM instance record. Matched via vm_inst_id (Azure) or object_id (AWS / Xen). cmdb_serial_number — Queried for UUID-type serial number used in Azure vm_inst_id matching. cmdb_rel_ci — Where Virtualized by::Virtualizes is written and stale relationships are deleted. cmdb_rel_type — Relationship type resolved via hardcoded sys_id d93304fb0a0a0b78006081a72ef08444. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Troubleshooting Relationship Not Created — AWS Check object_id on the server CI — Must contain the EC2 instance_id. Empty means the pattern did not run or conditions were not met. Check manufacturer — Must contain "amazon". Any other value causes the post sensor to exit at the manufacturer gate. Check VM instance record in CMDB — Query cmdb_ci_vm_instance WHERE object_id = [EC2_instance_id]. No record means AWS Cloud Discovery has not run or the instance is not in the CMDB. Check shouldDiscoverAmazon (Linux only) — Must be enabled in the Discovery schedule. Relationship Not Created — Azure Check object_id on the server CI — Must contain the converted UUID. Empty means the pattern did not run or conditions were not met. Check manufacturer — Must contain "microsoft". Check VM instance record in CMDB — Query cmdb_ci_vm_instance WHERE vm_inst_id IN [object_id, uuid_serial_number]. No record means Azure Cloud Discovery has not run. Check UUID format mismatch — Check SMBIOS version on the server. If ≤ 2.5, the big-endian conversion may have produced a different value than what Azure Cloud Discovery stored in vm_inst_id. Check uuidSerial (Linux only) — If empty, check sudo configuration for the Discovery credential. Post Sensor Not Running At All Check post sensor record — Confirm Active = true and that it has not been customised. object_id Populated but Relationship Still Not Created Manufacturer does not match — Manufacturer on the CI does not contain microsoft, amazon, or xen. Post sensor exits at the manufacturer gate regardless of object_id. All VM instance records are terminated — Post sensor uses the terminated record as a last resort if it is the only option. Confirm Cloud Discovery is correctly updating instance state in cmdb_ci_vm_instance. Wrong VM Instance in the Relationship Relationship points to old VM instance — object_id on the computer CI does not match the current VM instance. Post sensor creates the correct one on the next Discovery run once object_id is corrected. Multiple non-terminated instances match — Post sensor picks the first non-terminated record. Investigate and resolve duplicates in cmdb_ci_vm_instance.