Discovering a vCenter Server

Download this manual as a PDF file

The following sections describe how to discover a vCenter server and component devices for monitoring by SL1 using the VMware: vSphere Base Pack PowerPack.

Use the following menu options to navigate the SL1 user interface:

  • To view a pop-out list of menu options, click the menu icon ().
  • To view a page containing all of the menu options, click the Advanced menu icon ().

Discovering a vCenter Server

You can discover your vCenter server using the guided discovery process in SL1.

The guided discovery process lets you select a discovery type specific to the type of devices you want to monitor, in addition to traditional SNMP discovery. The guided discovery wizard provides a filtered list of relevant credentials, the ability to create new credentials, and a reduced set of application-specific fields to help you efficiently discover the devices you need.

The guided discovery process requires SL1 platform version 11.2.1 or later. If you are using an earlier version of SL1, you should use the unguided discovery process for discovering a vCenter Server.

To discover your vCenter server using guided discovery:

  1. On the Devices page () or the Discovery Sessions page (Devices > Discovery Sessions), click the Add Devices button. The Select page appears:

    Image of the Discovery start page

  2. Select the VMware discovery type. Additional information about the requirements for device discovery appears in the General Information pane to the right.

  1. Click Select. The Credential Selection page appears, which is the first step in the guided discovery session:

Image of the Credential Selection page

  1. On the Credential Selection page, select the VMware credential you configured.

  1. On the Credential Selection page of the guided discovery process, select a credential to allow SL1 to access the vCenter server, and then click Next. The Root Device Details page appears, which is the second step in the guided discovery session:

Image of the Root Device Details page

  1. Complete the following fields:
  • Root Device Name.  Type the name of the root device for the application you want to monitor (in this case, an Amazon Web Services root device).
  • IP Address. Enter the IP address for the vCenter server.
  • Select the organization to add discovered devices to. Select the name of the organization to which you want to add the discovered device.
  • Collector Group Name. Select an existing collector group to communicate with the discovered device. This field is required.

  1. Click Next. SL1 creates a root device with the appropriate Device Class assigned to it and aligns the relevant Dynamic Applications. The Final Summary page appears, which is the third and final step of the guided discovery session:

Image of the Final Summary page

  1. Click Close.

The results of a guided discovery do not display on the Discovery Sessions page (Devices > Discovery Sessions). However, you can retrieve details of saved Guided Discovery Sessions with the guidedDiscoverySessions GraphQL query. Details for discovery sessions that create a virtual root device are not currently displayed in the user interface.

Discovering a vCenter Server Using Unguided Discovery

To create and run a discovery session that will discover a vCenter server, perform the following steps:

  1. On the Devices page () or the Discovery Sessions page (Devices > Discovery Sessions), click the Add Devices button. The Select page appears:

Image of the Add Devices wizard, page 1

  1. Click the Unguided Network Discovery button. Additional information about the requirements for discovery appears in the General Information pane to the right.
  1. Click Select. The Add Devices page appears:
  2. Complete the following fields:
  • Name. Type a unique name for this discovery session. This name is displayed in the list of discovery sessions on the Discovery Sessions tab.
  • Description. Optional. Type a short description of the discovery session. You can use the text in this description to search for the discovery session on the Discovery Sessions tab.
  • Select the organization to add discovered devices to. Select the name of the organization to which you want to add the discovered devices.

  1. Click Next. The Credentials page of the Add Devices wizard appears:

Image of the Add Devices wizard, page 2

  1. On the Credentials page, locate and select the SOAP/XML credential you created. If the Windows server that hosts the vCenter server is SNMP-enabled, then additionally select an SNMP credential for the vCenter server.
  1. Click Next. The Discovery Session Details page of the Add Devices wizard appears:

Image of the Add Devices wizard, page 2

  1. Complete the following fields:
  • List of IPs/Hostnames. Type the IP address for the vCenter server.

  • Which collector will monitor these devices?. Select an existing collector to monitor the discovered devices. Required.
  • Run after save. Select this option to run this discovery session as soon as you click Save and Close.

In the Advanced options section, click the down arrow icon () to complete the following fields:

  • Discover Non-SNMP. If the Windows server that hosts the vCenter server is not SNMP-enabled, then you must enable this setting.
  • Apply Device Template. Select the device template that you created for VMware.

  1. Click Save and Close to save the discovery session. The Discovery Sessions page (Devices > Discovery Sessions) displays the new discovery session.
  2. If you selected the Run after save option on this page, the discovery session runs, and the Discovery Logs page displays any relevant log messages. If the discovery session locates and adds any devices, the Discovery Logs page includes a link to the Device Investigator page for the discovered device.

Discovering a vCenter Server in the SL1 Classic User Interface

To create and run a discovery session that will discover a vCenter server, perform the following steps:

  1. Go to the Discovery Control Panel page (System > Manage > Classic Discovery).
  2. Click the Create button to create a new discovery session. The Discovery Session Editor modal page appears:

  1. Enter values in the following fields:
  • IP Address Discovery List. Type the IP address for the vCenter server.

  • SNMP Credentials. If the Windows server that hosts the vCenter server is SNMP-enabled, then select the SNMP credential for the vCenter server in this field. If you do not select an SNMP credential in this field, then you must select the Discover Non-SNMP checkbox.

  • Other Credentials. Select the SOAP/XML credential that you created for VMware.
  • Discover Non-SNMP. If the Windows server that hosts the vCenter server is not SNMP-enabled, then you must select this checkbox.
  • Apply Device Template. Select the device template that you created for VMware.
  1. Optionally, you can enter values in the other fields on this page. For more information about the other fields on this page, see the Discovery & Credentials manual.
  2. Click the Save button and then close the Discovery Session Editor modal page.
  3. The discovery session you created will appear at the top of the Discovery Control Panel page. Click its lightning-bolt icon () to run the discovery session.
  4. The Discovery Session window appears. When the vCenter server is discovered, click its device icon () to view the Device Properties page for the vCenter server.

Configuring the VMware Dynamic Applications

The following sections describe how to configure some of the Dynamic Applications in the VMware: vSphere Base PackPowerPack .

Configuring the "VMware: Events" Dynamic Application

The "VMware: Events" Dynamic Application is designed to collect events from VMware devices using the VMware API and insert those events into the device log of the aligned vCenter server.

For SL1 to insert VMware events into the device log, the Data Collector that monitors the vCenter server must be configured to process API events. For instructions on how to configure a Data Collector to process API events, the section on Global Settings.

You can specify which types of events the "VMware: Events" Dynamic Application collects by editing the event dictionary Python script located in the "VMware Event Collection" snippet of the "VMware: Events" Dynamic Application. This event dictionary includes a series of rows that look like this: 

"ClusterStatusChangedEvent": {"count": 0, "countAll": 0, "collect": True},

Each row begins with an event type. This event type value must match the "eventTypeId" value the VMware API uses in its "EventFilterSpec" data object to indicate which events should be collected. For more information, see VMware's documentation on the "EventFilterSpec" data object.

To specify which events the "VMware: Events" Dynamic Application collects:

  1. Go to the Dynamic Applications Manager page (System > Manage > Applications).
  2. Click the wrench icon () for the "VMware: Events" Dynamic Application. The Dynamic Applications Properties Editor page appears.
  3. Click the Snippets tab. The Dynamic Applications Snippet Editor & Registry page appears.
  4. Click the wrench icon () for the "VMware Event Collection" snippet.

  1. Locate the section that looks like this:

event_dict = {

"AlarmStatusChangedEvent": {"count": 0, "countAll": 0, "collect": True},

"ClusterStatusChangedEvent": {"count": 0, "countAll": 0, "collect": True},

"HostStatusChangedEvent": {"count": 0, "countAll": 0, "collect": True},

"UserLoginSessionEvent": {"count": 0, "countAll": 0, "collect": True},

"UserLogoutSessionEvent": {"count": 0, "countAll": 0, "collect": True},

"VmEvent": {"count": 0, "countAll": 0, "collect": True},

"VmMigratedEvent": {"count": 0, "countAll": 0, "collect": True},

"other": {"count": 0, "countAll": 0, "collect": False},

}

  1. Following the format shown above, add new rows for any additional event types you want to include in the event dictionary or delete the rows of any event types you want to remove from the event dictionary.

  1. For each event type listed in the event dictionary:
  • If you want the Dynamic Application to collect that event type, change the "collect" value to "True". For example:

    • "AlarmStatusChangedEvent": {"count": 0, "countAll": 0, "collect": True},

  • If you do not want the Dynamic Application to collect that event type, change the "collect" value to "False". For example:

    • "UserLoginSessionEvent": {"count": 0, "countAll": 0, "collect": False},

  • If you want the Dynamic Application to collect all event types, locate the "other" line and change the "collect" value to "True". For example:

    • "other": {"count": 0, "countAll": 0, "collect": True},

Changing the "other" "collect" value to "True" overrides any event types with a "collect" value of "False". If you do not want to collect all event types, then you must either remove the "other" row or change its "collect" value to "False".

The default value for the "other" "collect" is set to "False" and if not changed, will stop collection for all event types that are not explicitly listed and set to "True".

  1. Click the Save button.
  2. Reset the event session using the "Reset Sessions" Dynamic Application to ensure your changes take effect. (For more information, see the "Resetting the VMware vSphere Session" section of this manual.)

If you have edited the "VMware Event Collection" snippet and want to maintain your event_dict settings the next time the PowerPack is upgraded, you must copy the event dictionary Python script, install the new version of the PowerPack, and then follow the steps in this section to paste the settings into the "VMware Event Collection" snippet in the upgraded version of the "VMware: Events" Dynamic Application.

Configuring the Polling Frequency for VMware Performance Dynamic Applications

In the VMware: vSphere Base Pack PowerPack, some of the Dynamic Applications require that their Poll Frequency be set to a specific time to ensure the accuracy of the data they collect.

If there is a need to change the polling from the shipped values, vCenter performance is likely to be affected. Other configurations of the values are not recommended and/or guaranteed to work correctly.

To set the polling frequency: 

  1. Go to the Dynamic Applications Manager page (System > Manage > Applications).
  2. Search for the Dynamic Application whose polling frequency you want to update and click on its wrench icon ().
  3. In the Dynamic Applications Properties Editor, use the drop-down in the Poll Frequency field to select the polling frequency.

  1. Set the polling frequencies for the following Dynamic Applications using the guidelines listed:
  • VMware: VirtualMachine CPU Performance. No more than 5 minutes.
  • VMware: VirtualMachine Datastore Performance. No more than 5 minutes.
  • VMware: VirtualMachine Disk Performance. No more than 5 minutes.
  • VMware: Inventory Cache. Exactly 1 minute.
  • VMware: Datastore Space Performance. No less than 15 minutes.

Using Collector Affinity with VMware Dynamic Applications

Collector Affinity specifies the Data Collectors that are allowed to run collection for Dynamic Applications aligned to component devices.

NOTE: The Collector Affinity feature is available only in SL1 versions 8.9.0 and greater, and applies only to distributed SL1 systems, not All-In-One Appliances.

If there is a need to change the Collector Affinity settings, performance is likely to be affected. Other configurations of the values are not recommended and/or guaranteed to work correctly.

By default, the Dynamic Applications in the VMware: vSphere Base Pack PowerPack are configured so that the Data Collector assigned to the root device will collect data for any Dynamic Applications in the PowerPack that are auto-aligned to component devices during discovery. This guarantees that data for all of the Dynamic Applications aligned to all of your VMware components will be collected by a single Data Collector.

When monitoring a VMware environment with a large number of component devices, however, running all of the Dynamic Applications on the root device's Data Collector could potentially overload the Data Collector, either because the Dynamic Applications take too long to complete or because they consume too much CPU or memory. When this occurs, some data might not be collected. This can lead to missed alerts and events, as well as gaps in graphs and reports.

To better support such large VMware environments, you can distribute the load of the VMware Bulk Performance Dynamic Applications across the Data Collectors in a collector group by changing the Collector Affinity setting for those Dynamic Applications to Assigned Collector. When the VMware Bulk Performance Dynamic Applications are configured this way, SL1 monitors the load on each Data Collector in the collector group and tries to evenly distribute the VMware Bulk Performance Dynamic Applications across the Data Collectors, thereby reducing total collection latency. It also has the benefit of distributing the PowerPack's CPU load and memory utilization.

The "VMware: HostSystem Datastore Performance", "VMware: ResourcePool Performance", and VMware: VirtualMachine DataStore Performance" Dynamic Applications are exceptions, and their Collector Affinity values must be changed to Root Device Collector.

The Collector Affinity value should be changed to Assigned Collector only for VMware Bulk Performance Dynamic Applications (with the exception of the ones listed in the previous note). The VMware Configuration Dynamic Applications must run on the VMware root device's Data Collector. As such, their Collector Affinity values should remain set Root.

NOTE: The VMware: vSphere Base PackPowerPack automatically updates the Collector Affinity values to the correct settings.

All Bulk Performance Dynamic Applications, except 'VMware: ResourcePool Performance', were updated in version 212 of the PowerPack to allow data to be cached on a local collector so virtual machines can be assigned to any collector.

For more information about configuring Collector Affinity settings for Dynamic Applications, see the Collector Affinity topic of the Dynamic Application Development section.

Configuring the "VMware: Tag Configuration" Dynamic Application

By default the "VMware: Tag Configuration" Dynamic Application is disabled. Once enabled, you can use the data collected by this Dynamic Application to populate custom attributes for device groups. To do this, you need to define some of the fields as Custom Attributes.

To do this:

  1. Go to the Dynamic Applications Manager page (System > Manage > Applications).
  2. Find the "VMware: Tag Configuration" Dynamic Application and click its wrench icon ().
  3. Click the Collections tab. In the Collection Objects page, click the wrench icon () for the Category object.
  4. In the Custom Attribute field, select Dynamic Name. Click the Save button.
  5. Click the wrench icon for Assigned Tag. In the Custom Attribute field, select Dynamic Value, and then select Category in the second dropdown menu.
  6. Click the Save button.

For more information about Custom Attributes, see the Using Custom Attributes section.

Collecting Custom Performance Metrics

vSphere Performance Collection

The VMware: vSphere Base Pack PowerPack enables you to collect custom performance metrics.

To add a new vSphere performance metric:

  1. In the Dynamic Applications Manager page (System > Manage > Applications), find the Bulk Snippet Performance Dynamic Application aligned to the particular device type of interest( i.e., Virtual Machine or Datastore). Click on the wrench icon () next to the Dynamic Application to open theDynamic Applications Properties Editor page.
  2. In the Collections tab, clone an existing collection object by selecting the wrench icon () next to the object you want to clone.
  3. Add a new object name and metric label using the Snippet Arguments field.

The metric label format is: <metric_group>.<metric_name>.<rollupType>.

  1. Click Save As to save the collection object as a new object without saving over the object that you cloned.

Details about the precise metric name, group, and rollup type can be found in the vSphere documentation for PerformanceManager. The vCenter managed object browser (MOB) at https://<vCenter IP>/mob/?moid=PerfMgr is an alternative source for counter labels if you know the counter ID. If it is decided that a new snippet must be added to the performance Dynamic Application, the following snippet code can be used as the basis for the new snippet:

from content import content_errors

 

from content import content_logger

 

from silo_vmware.VMwareBulkPerfMetrics import VMwareBulkPerfMetrics

CONTROL_PARAMS = {

# 'maxThreads': 8, # maximum number of threads per execution

# 'maxQueryMetrics': 64, # maximum number of metrics to include in QueryPerf, default is 64 or comes from API if set

# 'intervalId': 300 # Default vCenter performance statistical interval

}

 

with content_errors.ErrorManager(self):

with content_logger.LogManager(self) as logger:

app_name = "VMwareClusterComputeResourcePerformanceSnippet"

inst = VMwareBulkPerfMetrics(self, app_name, snippet_id, devices, self.oids, entity_type='ComputeResource', ctrl_params=CONTROL_PARAMS)

inst.process()

VSAN Performance Collection

The process for VSAN performance collection is similar to the process for vSphere performance collection, but the snippet argument uses a URL-style pattern to designate the metric to be collected. Refer to the VSAN Management API documentation for more information.

For example, for VSAN cluster front-end stats, the collection object snippet arguments use a pattern similar to this, where the entity type and metric can be exchanged with the new metric of interest:

vsan://vsan-performance-manager/VsanPerfQueryPerf?entityType=cluster-domclient&entityUuid=*&metricLabel=congestion

Details on the precise parameters that can be provided to the query can be found in the vSphere documentation for VsanPerfQueryPerf.

If a new snippet is required, the following snippet code can be used as the basis for the new snippet:

from content import content_errors

from content import content_logger

from silo_vmware_vsan.vsan_perf_app_collector import VsanPerfAppCollector

TAG = "VsanStoragePerfStats"

with content_errors.ErrorManager(self):

with content_logger.LogManager(self) as logger:

vsan_app = VsanPerfAppCollector(self, TAG, snippet_id)

vsan_app.get_collections()

vsan_app.collect()

vsan_app.store()

Viewing Component Devices

When SL1 performs collection for the "VMware: RootFolder Datacenter Discovery" Dynamic Application, SL1 will create component devices for the components managed by the vCenter server and align other Dynamic Applications to those component devices. Some of the Dynamic Applications aligned to the component devices are also used to create additional component devices. All component devices appear on the Devices page.

During initial discovery, SL1 requests information about 200 devices per poll period until all component devices are discovered. After initial discovery, SL1 requests only the changes from the previously collected topology. If you have a large VMware infrastructure, it can take several collection cycles after the initial collection of the "VMware: RootFolder Datacenter Discovery" Dynamic Application for all component devices to be discovered.

In addition to the Devices page, you can view the vCenter server and all associated component devices in the following places in the user interface:

  • The Device Investigator Map page (click Map in the Device Investigator page) displays a map of a particular device and all of the devices with which it has parent-child relationships. Double-clicking any of the listed devices reloads the page to make the selected device the primary device.

 

  • The Device Components page (Devices > Device Components) displays a list of all root devices and component devices discovered by SL1. The Device Components page displays all root devices and component devices in an indented view, so you can easily view the hierarchy and relationships between child devices, parent devices, and root devices. To view the component devices associated with a vCenter server, find the vCenter server and click its plus icon (+).

 

  • The Component Map page (Classic Maps > Device Maps > Components) allows you to view devices by root node and view the relationships between root nodes, parent components, and child components in a map. This makes it easy to visualize and manage root nodes and their components. SL1 automatically updates the Component Map as new component devices are discovered. The platform also updates each map with the latest status and event information. To view the map for a vCenter server, go to the Component Map page and select the map from the list in the left NavBar. To learn more about the Component Map page, see the section on Maps.

Relationships with Other Types of Component Devices

In addition to the parent/child relationships between component devices, the following relationships are automatically created by the Dynamic Applications in the VMware: vSphere Base Pack PowerPack:

  • VMware Virtual Machines and VMware Datastores

  • VMware Virtual Machines and VMware Networks
  • VMware Virtual Machines and Cisco Cloud Center
  • VMware Virtual Apps and VMware Networks
  • VMware Hosts and VMware Datastores
  • VMware Hosts and VMware Networks
  • VMware Hosts and VMware Virtual Machines
  • VMware Datastore Clusters and VMware Virtual Machines
  • VMware Datastore Clusters and VMware Host Clusters
  • VMware Datastore Clusters and VMware Hosts

SL1 can also automatically build relationships between VMware component devices and other associated devices. If you discover one or more of the following:

  • A Dynatrace host using the Dynamic Applications in the Dynatrace PowerPack
  • A Cisco UC VOS application using the Dynamic Applications in the Cisco: UC VOS PowerPack
  • A Cisco CUCM cluster using the Dynamic Applications in the Cisco: CUCM PowerPack
  • An EMC VNX device using the Dynamic Applications in the EMC: VNX PowerPack

  • A NetApp device using the Dynamic Applications in the NetApp Base Pack PowerPack
  • A UCS device using the Dynamic Applications in the Cisco: UCS PowerPack

SL1 automatically creates relationships between the following types of component devices, where appropriate:

  • Dynatrace hosts and VMware Datastores
  • Cisco UC VOS applications and VMware Datastores
  • Cisco CUCM clusters and VMware Datastores
  • EMC VNX LUNs and VMware Datastores

  • NetApp LUNs and VMware Datastores
  • VMware Hosts and UCS Service Profiles

Determining Availability for Component Devices

The Dynamic Applications that discover the component devices managed by a vCenter server include collection objects that define the availability status of those component devices.

The hosts folder contains three parent device classes and one child device class for the virtual machines:

  • Compute Clusters (Parent)

  • Resource Pools (Parent)

  • Hosts (Parent)

  • Virtual Machines (Child)

Depending upon VMware vSphere configuration, different virtual machines could be associated to any or all of the three parent device types.

 

VMware vSphere includes three types of component devices that are considered unavailable if a vCenter server reports that the power state is off:

  • Compute Resource

  • Host Server (i.e., ESX and ESXi Servers)
  • Virtual Machine

The following types of component devices are considered unavailable if a vCenter server loses its connection to an ESXi hypervisor host server:

  • Host Server
  • Virtual Machine

The following types of component devices are considered unavailable if a vCenter server does not include information about those components in the appropriate response:

  • Distributed Virtual Switch

  • Distributed Virtual Portgroup
  • Folder
  • Network
  • Resource Pool

The following types of component devices are considered unavailable based on other conditions:

  • Datastore. A datastore is considered unavailable if it is not accessible. A datastore is not accessible if no hosts have successfully mounted the datastore volume.
  • Cluster. A cluster is considered unavailable if no hosts are associated with the cluster or all hosts associated with the cluster are powered off.

When a VMware device is shut down, an event is created to alert the user that the device is unavailable. If you turn off VMware devices intentionally, you can suppress these availability events.

To suppress these events:

  • Create a device group that contains the VMware devices for which you want to suppress availability events.
  • Suppress that device group in the relevant Event Policies.

To create the device group:

  1. Go to the Device Groups page (Devices > Device Groups or Registry > Devices > Device Groups in the SL1 classic user interface).

  1. Click the Create button. The Device Group Editor page appears:

  1. Enter values in the following fields:
  • Device Group Name. In this field you can enter a customized Device Group Name. For example, "Event Suppressed VMs".
  • Visibility. Select Event Suppression.

  1. If you want to suppress one or a few individual devices, click the Add button under the Static Devices and Groups pane and select Add Devices. The Device Alignment modal page appears:

  1. In the Device Alignment modal page, perform a search in the Class | Sub-class column for "Virtual Machine" to bring up the available VMware devices.
  2. Find the device(s) for which you want to suppress availability events and select their checkbox ().
  3. Click the Add/Remove button to add the device(s).

  1. To add all VM devices to the device group, click the Add button in the Dynamic Rules pane of the Device Group Editor page. The Device Group Rule Editor page appears:

  1. In the Device Group Rule Editor page, select the checkbox () for Device Class in the Active Selectors pane.

  1. In the Selector Definitions pane, the Device Class field appears. Perform a search for "VMware" in the Device Class field, and select VMware | Virtual Machine. All virtual machines will appear in the Matched Devices pane:

  1. Click the OK button. The Device Class will appear in the Dynamic Rules pane.

Next, you need to suppress two Event Policies for this Device Group.

To suppress two Event Policies for this Device Group:

  1. Go to the Event Policies page (Events > Event Policies).

  1. Perform a search for "Availability".

  1. Locate the Poller: Availability Check Failed policy, click the actions icon () and select Edit. The Policy Description page appears. Click the Suppression tab.

  1. In the Device Groups pane, click the Select Device Groups button.
  2. In the Available Device Groups window, locate the device group you created and select its checkbox. Click the Select button. The selected device group now appears in the Device Groups pane.
  3. Click the Save button.
  4. Repeat these steps for the Poller: Availability Healthy event policy to suppress events that will occur when a VMware device is turned back on again.

To suppress the two Event Policies in the SL1 classic user interface:

  1. Go to the Event Policy Manager page (Registry > Events > Event Manager).
  1. Perform a search in the Event Policy Name column for "Availability".

  1. Click the wrench icon () for the Poller: Availability Check Failed policy. The Event Policy Editor page appears:

  1. Click the Suppressions tab in the Event Policy Editor page.
  2. In the Available Device Groups field, select the device group you created. In this example, you would select Event Suppressed VMs.
  3. Click the right arrow button, >>, and the device group moves to the Suppressed Device Groups field.
  4. Click the Save button.
  5. Repeat these steps for the Poller: Availability Healthy event policy to suppress events that will occur when a VMware device is turned back on again.

Limitations of Merged Devices

If you merge a VMware virtual machine component with a physical device, be aware of the following limitations:

  • When you merge a VMware virtual machine with a physical device, such as a Window or Linux server, you should ensure that the virtual machine and the physical device are assigned to the same collector group.

  • When a virtual machine is moved, dropped, or deleted, the corresponding physical device record is deleted via vanish/purge.

  • The VMware: vSphere Base Pack PowerPack aligns Internal Collection Dynamic Applications when you merge a device. When you unmerge a device, you should manually unmerge the "VMware: VirtualMachine IC Uptime" Dynamic Application from the physical device.