Solaris Zones Pattern doesn't create VM instance to VM Server and VM Server to Solaris Zone relationshipsDescriptionSolaris Server and Solaris Zones discovery results must be merged where the contact point is a Solaris Server CI created for every Solaris Zones non-global domain (VM).If you have this issue when you run Solaris Server discovery and you discover Solaris Zones global domain (Host) only Solaris Server records for guests won't be created. Steps to Reproduce 1. Run discovery against 10.196.103.185a. It must create following relationships- Zones -- Runs on : Runs --> Solaris Server (= Solaris Global Zone (server where the hypervisor is running)- Zones -- Registered on : Has registered --> Solaris Virtual Machine Instance2. Solaris Server (a server CI for each non-global Solaris Zone) is missing3. Solaris Server -- Instatites : Instatiated by --> Solaris Virtual Machine Instance is missing4. Solaris Server -- Virtualized by : Virtualizes --> Zones is missingThis PRB / DEFECT has been created due to CSTASK333620.WorkaroundSolaris Zones Discovery Details Solaris Zones have to be discovered from the host and from the guest perspective which means you have to make sure global and non-global IP addresses will be included in your IP discovery scope. The discovery order is irrelevant because discovery will merge discovery results in either cases. It doesn't matter if you discover VMs at before the host. Global Zone Discovery (Host) Kubernetes Zones discovery requires successful discovery of the host (global zone) and all guests (non-global zones). If you run discovery at the host only, dummy server CI (cmdb_ci_solaris_server) records will be created, and they will have name and correlation_id fields populated only. To enrich them it's recommended to run Solaris Server discovery for each Solaris server regardless if it is virtual or physical A guest is a dummy server which has a server name and a correlation_id defined only. It is a prerequisite step for successful relationships creation. The next image show created relationships among virtual servers, VM instances and zones Non-Global Zone Discovery (Guests) The next step is to discover guests because by runing Solaris Server pattern again. Solaris Server discovery will SSH to VM servers. As you can notice zone07.ncavar.lab is a contact point and we have to make sure Solaris Server pattern resolved all servers in the same way. The consistent name resolution means ServiceNow recommends using only one name resolution method across whole enterprise if possible. Consistency is the key for successful discovery and mapping. It's a good practice to use one method exclusively. HINT: Don't mix hostnames and FQDNs! The Guest VM has been discovered. If MySQL is installed it will be discovered and your users will know MySQL is running in VM hosted by Solaris Zones.The next image shows the server relationship to the zone and to the VM instance. Caveats Configured DNS Servers If the customer is using fully qualified domain names and glide.discovery.hostname.include_domain = true enforces then the consisten DNS usage is recommended. ServiceNow relies Configured DNS servers Solaris and it extracts domain from /etc/resolv.conf file like in the example below root@zone07:/# cat /etc/resolv.conf search ncavar.lab domain ncavar.lab nameserver 10.196.39.211 Assumptions Global zones and hosted VMs share the same DNS domain name Non-global zone names match hostnames Non-global zone names do not include domains DNS name resolution has been tested only. NIS and /etc/hosts files are not supported. CMDB Cleanup solaris_zones_and_vm_instances_without_relationships.js The script search for all cmdb_ci_vm_zones and cmdb_ci_solaris_instance records which don't have any relationships. By design cmdb_ci_vm_zones records must have at least relationships to the hosting cmdb_ci_solaris_server and all cmdb_ci_solaris_instance records If you have to delete records change var deleteit = false; to var deleteit = tue; and uncomment setWorkflow and deleteRecord If you don't understand these instructions please open a case and ServiceNow Support will help you. var deleteit = false; gs.log('--------------------------------------------------------'); gs.log(' cmdb_ci_vm_zones'); gs.log('--------------------------------------------------------'); var zones_to_be_deleted = 0; var zonesCmdb = new GlideRecord('cmdb_ci_vm_zones'); zonesCmdb.query(); while(zonesCmdb.next()) { var downRelZone = new GlideRecord('cmdb_rel_ci'); downRelZone.addQuery('parent', zonesCmdb.sys_id); downRelZone.query(); var down = downRelZone.getRowCount(); // gs.log(' DOWN: ' + down); var upRelZone = new GlideRecord('cmdb_rel_ci'); upRelZone.addQuery('child', zonesCmdb.sys_id); upRelZone.query(); var up = upRelZone.getRowCount(); // gs.log(' UP: ' + down); var rels = down + up; if(rels == 0) { gs.log('ZONE: name [' + zonesCmdb.name + '] sys_id [' + zonesCmdb.sys_id + ']'); if (!deleteit) { gs.log(' PLAN: Delete due to missing relationships!'); } else { gs.log(' Delete due to missing relationships [None]!'); // UNCOMMENT // zonesCmdb.setWorkflow(false); // zonesCmdb.deleteRecord(); } zones_to_be_deleted = zones_to_be_deleted + 1; continue } } gs.log('--------------------------------------------------------'); gs.log(' cmdb_ci_solaris_instance'); gs.log('--------------------------------------------------------'); var instances_to_be_deleted = 0; var instCmdb = new GlideRecord('cmdb_ci_solaris_instance'); instCmdb.query(); while(instCmdb.next()) { var downRelInst = new GlideRecord('cmdb_rel_ci'); downRelInst.addQuery('parent', instCmdb.sys_id); downRelInst.query(); var down = downRelInst.getRowCount(); // gs.log(' DOWN: ' + down); var upRelInst = new GlideRecord('cmdb_rel_ci'); upRelInst.addQuery('child', instCmdb.sys_id); upRelInst.query(); var up = upRelInst.getRowCount(); // gs.log(' UP: ' + down); var rels = down + up; if(rels == 0) { gs.log('SOLARIS INSTANCE: name [' + instCmdb.name + '] sys_id [' + instCmdb.sys_id + ']'); if (!deleteit) { gs.log(' PLAN: Delete due to missing relationships!'); } else { gs.log(' Delete due to missing relationships [None]!'); // UNCOMMENT // instCmdb.setWorkflow(false); // instCmdb.deleteRecord(); } instances_to_be_deleted = instances_to_be_deleted + 1; continue } } gs.log('========================================================'); gs.log('ZONES:'); gs.log(' - to be deleted: ' + zones_to_be_deleted); gs.log('INSTANCES:'); gs.log(' - to be deleted: ' + instances_to_be_deleted); There might be more steps which are instance specific and they require further analysis Limitations(s) The Wrong IP Address assigned to Virtual Machine Servers (cmdb_ci_solaris_server) According to the official Solaris Discovery document this is not a bug because ServiceNow, according to the design, doesn't populate cmdb_ci_solaris_server.ip_address field. However, every administrator can include IP address in the Solaris Server list which will reveal IP address. If that is the case users will notice every non-global VM server has inherited the Solaris Zone global domain server IP address. All server IP addresses are available as related cmdb_ci_ip_address CIs. Solaris Discovery correctly creates related network adapters, populates network adapters by IP addresses and it creates relationships to all discovered IP addresses. Workaround If you've reach this point please open a Support case and they will help you. The attached zip file contains sys_remote_update_set_61e63c918724111056bb97573cbb35fc.xml update set which contains other files from the zip. The fix has been targeted for the ITOM Visibility Content 202210 release CSTASK333620_solaris_zones_update_set.zip Related Problem: PRB1588033