Contents IT Operations Management Previous Topic Next Topic Data collected by Discovery on Solaris zones Subscribe Log in to subscribe to topics and get notified when content changes. ... SAVE AS PDF Selected Topic Topic & Subtopics All Topics in Contents Share Data collected by Discovery on Solaris zones Discovery maps the relationships between global and local Solaris zones upon detection. Solaris zone topology In the following example, a Solaris global zone contains two local zones: zone01 and zone02. Each local zone is represented by a physical Solaris CI record and a Virtual Machine Instance record. Each of the local zones is tied to a Zone Server, demonstrating how virtualization relates to the global zone (mmp1). Figure 1. Solaris zone relationship map Use cases The TCP connection and process information for local zone servers must be collected by running commands on their parent global zone. The relationship path between the local and global zone physical machines must be established before TCP connection and process information for local zone servers can be collected. Case 1: Global zone discovered first. The system creates the Solaris server CI for the global zone. Discovery detects the local zones, creates a hypervisor zone server record, and creates a virtual machine instance record for each Solaris device in the local zone. Discovery creates the relationship between the hypervisor record and the VM instance record. Case 2: Local zone discovered first. The system creates the Solaris server CI for the local zone. Discovery sets the correlation ID, so that it can be reconciled during later global zone discoveries. Case 3: Global zone discovered after creation of local zone Solaris server CIs. Global zone Discovery detects local zones. Discovery creates a hypervisor zone server record, and creates a virtual machine instance record for each Solaris device in the local zone. Discovery creates the relationship between the hypervisor record and the VM instance record. In addition, it creates the relationship between the physical local zone VM and its virtual machine instance record. The global zone runs the Solaris - ADM probe on itself, filtering by the local zone, and updates the physical local zone VMs with this data. Case 4: The relationship path between physical local and global zone machines is established.Subsequent discoveries of the global zone refresh the TCP connection and process information for the contained local zones. ECC queue payload When the system discovers a global zone, the Solaris - Zones & ADM Launcher probe triggers the Solaris - ADM probe to explore the global zone and each local zone found. Because the Solaris - ADM probe must run on the global zone to detect TCP connection and process information from its local zones, you might see multiple ECC queue records that appear identical. Figure 2. ECC queue entries for a zone Discovery Upon examining the payload, however, you will see that each probe is actually targeting a different zone CI to filter on and update. Figure 3. Local zone payload Virtual machine data collected for zones Table 1. Data collected on Solaris zones Label Table Name Field Name Source Version cmdb_ci_vm_zones version zoneadm, zonename Correlation ID cmdb_ci_vm_zones correlation_id zoneadm, zonename Name cmdb_ci_vm_instance name zoneadm, zonename Parent cmdb_ci_vm_instance parent Internal CMDB CI cmdb_ci_vm_instance cmdb_ci Internal Correlation ID cmdb_ci_vm_instance correlation_id zoneadm, zonename On this page Send Feedback Previous Topic Next Topic
Data collected by Discovery on Solaris zones Discovery maps the relationships between global and local Solaris zones upon detection. Solaris zone topology In the following example, a Solaris global zone contains two local zones: zone01 and zone02. Each local zone is represented by a physical Solaris CI record and a Virtual Machine Instance record. Each of the local zones is tied to a Zone Server, demonstrating how virtualization relates to the global zone (mmp1). Figure 1. Solaris zone relationship map Use cases The TCP connection and process information for local zone servers must be collected by running commands on their parent global zone. The relationship path between the local and global zone physical machines must be established before TCP connection and process information for local zone servers can be collected. Case 1: Global zone discovered first. The system creates the Solaris server CI for the global zone. Discovery detects the local zones, creates a hypervisor zone server record, and creates a virtual machine instance record for each Solaris device in the local zone. Discovery creates the relationship between the hypervisor record and the VM instance record. Case 2: Local zone discovered first. The system creates the Solaris server CI for the local zone. Discovery sets the correlation ID, so that it can be reconciled during later global zone discoveries. Case 3: Global zone discovered after creation of local zone Solaris server CIs. Global zone Discovery detects local zones. Discovery creates a hypervisor zone server record, and creates a virtual machine instance record for each Solaris device in the local zone. Discovery creates the relationship between the hypervisor record and the VM instance record. In addition, it creates the relationship between the physical local zone VM and its virtual machine instance record. The global zone runs the Solaris - ADM probe on itself, filtering by the local zone, and updates the physical local zone VMs with this data. Case 4: The relationship path between physical local and global zone machines is established.Subsequent discoveries of the global zone refresh the TCP connection and process information for the contained local zones. ECC queue payload When the system discovers a global zone, the Solaris - Zones & ADM Launcher probe triggers the Solaris - ADM probe to explore the global zone and each local zone found. Because the Solaris - ADM probe must run on the global zone to detect TCP connection and process information from its local zones, you might see multiple ECC queue records that appear identical. Figure 2. ECC queue entries for a zone Discovery Upon examining the payload, however, you will see that each probe is actually targeting a different zone CI to filter on and update. Figure 3. Local zone payload Virtual machine data collected for zones Table 1. Data collected on Solaris zones Label Table Name Field Name Source Version cmdb_ci_vm_zones version zoneadm, zonename Correlation ID cmdb_ci_vm_zones correlation_id zoneadm, zonename Name cmdb_ci_vm_instance name zoneadm, zonename Parent cmdb_ci_vm_instance parent Internal CMDB CI cmdb_ci_vm_instance cmdb_ci Internal Correlation ID cmdb_ci_vm_instance correlation_id zoneadm, zonename
Data collected by Discovery on Solaris zones Discovery maps the relationships between global and local Solaris zones upon detection. Solaris zone topology In the following example, a Solaris global zone contains two local zones: zone01 and zone02. Each local zone is represented by a physical Solaris CI record and a Virtual Machine Instance record. Each of the local zones is tied to a Zone Server, demonstrating how virtualization relates to the global zone (mmp1). Figure 1. Solaris zone relationship map Use cases The TCP connection and process information for local zone servers must be collected by running commands on their parent global zone. The relationship path between the local and global zone physical machines must be established before TCP connection and process information for local zone servers can be collected. Case 1: Global zone discovered first. The system creates the Solaris server CI for the global zone. Discovery detects the local zones, creates a hypervisor zone server record, and creates a virtual machine instance record for each Solaris device in the local zone. Discovery creates the relationship between the hypervisor record and the VM instance record. Case 2: Local zone discovered first. The system creates the Solaris server CI for the local zone. Discovery sets the correlation ID, so that it can be reconciled during later global zone discoveries. Case 3: Global zone discovered after creation of local zone Solaris server CIs. Global zone Discovery detects local zones. Discovery creates a hypervisor zone server record, and creates a virtual machine instance record for each Solaris device in the local zone. Discovery creates the relationship between the hypervisor record and the VM instance record. In addition, it creates the relationship between the physical local zone VM and its virtual machine instance record. The global zone runs the Solaris - ADM probe on itself, filtering by the local zone, and updates the physical local zone VMs with this data. Case 4: The relationship path between physical local and global zone machines is established.Subsequent discoveries of the global zone refresh the TCP connection and process information for the contained local zones. ECC queue payload When the system discovers a global zone, the Solaris - Zones & ADM Launcher probe triggers the Solaris - ADM probe to explore the global zone and each local zone found. Because the Solaris - ADM probe must run on the global zone to detect TCP connection and process information from its local zones, you might see multiple ECC queue records that appear identical. Figure 2. ECC queue entries for a zone Discovery Upon examining the payload, however, you will see that each probe is actually targeting a different zone CI to filter on and update. Figure 3. Local zone payload Virtual machine data collected for zones Table 1. Data collected on Solaris zones Label Table Name Field Name Source Version cmdb_ci_vm_zones version zoneadm, zonename Correlation ID cmdb_ci_vm_zones correlation_id zoneadm, zonename Name cmdb_ci_vm_instance name zoneadm, zonename Parent cmdb_ci_vm_instance parent Internal CMDB CI cmdb_ci_vm_instance cmdb_ci Internal Correlation ID cmdb_ci_vm_instance correlation_id zoneadm, zonename