Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Virtual System Monitoring Concepts

There are three main conceptual components to integrated virtual and physical monitoring using Hyper-V and VMware vSphere:

  • metrics for VMware vSphere virtual system components, mainly pertaining to resource usage, but also including power states
  • Uptime Infrastructure Monitor’s Sync (Hyper-V) / vSync (VMware) feature, the syncing engine that ensures VMware vSphere virtual system components and inventories are accurately mirrored in Uptime Infrastructure Monitor, as well as their basic, non-agent-based metric data
  • vSphere virtual system components that are monitored and managed as Uptime Infrastructure Monitor Elements; these include VMware vCenter servers, Hyper-V host servers, ESX servers, and VMs

In addition to understanding these concepts, it is important that you also understand the way other Uptime Infrastructure Monitor functions change in a VMware vSphere virtual system monitoring context.

About Uptime Infrastructure Monitor Sync/vSync

The core of integrated monitoring is Uptime Infrastructure Monitor’s Sync/vSync, whose key functions are replicating metrics and mirroring topologies, from VMware vSphere the virtual systems to Uptime Infrastructure Monitor.

Sync/vSync takes performance metrics gathered by Hyper-V and VMware vSphere, normally for use in VMware tools such as the vSphere Client, and represents them in Uptime Infrastructure Monitor. VMware vSphere metrics Metrics that are available in Uptime Infrastructure Monitor include performance data for VMs, the Hyper-V and ESX servers that host them, and the VMware vCenter servers that manage your configurations (including but not limited to datacenters, clusters, and resource pools).

vSync also regularly monitors your VMware vSphere datacenter’s dynamic environment (including both physical and virtual assets), ensuring the VMware vSphere inventory that Uptime Infrastructure Monitor is using for monitoring and reporting is always current. For more information, see Managing Sync / vSync.


Virtual System Components as Uptime Infrastructure Monitor Elements

Some VMware vSphere virtual system components that act as logical groupings, including datacenters, clusters, resource pools, and vApps, are hierarchically mirrored in Uptime Infrastructure Monitor’s Infrastructure inventory, and are represented through their reported resource metrics. On the other hand, VMware vSphere virtual system components that are actual hosts, whether virtual or physical (i.e., a VMware vCenter server, its component ESX servers,or their respective VMs) are represented in Uptime Infrastructure Monitor as Elements.

When you add a VMware vCenter server as an Element, all of the VMware vSphere components, whether organizational or compute resources, as defined through the vSphere Client, are imported to Uptime Infrastructure Monitor, and their VMware/vSphere-collected metric data is migrated to the Uptime DataStore. Additionally, all ESX servers and VMs also become Elements. Similar functionality occurs when you add a Hyper-V host server as an Element.

There will be cases where administrators will want to actively manage which Hyper-V host or ESX server Elements (and subsequently, which VMs) are monitored by Uptime Infrastructure Monitor. For example, licensing constraints may prevent you from monitoring every ESX server in Uptime Infrastructure Monitor, or the performance of particular portions of your virtual infrastructure may not be considered mission critical, and demand the same level of up-time.

In these cases, administrators can include or exclude specific Uptime Infrastructure Monitor Elements from monitoring. Exclusions can be made on a per-VM basis, or by a logical grouping at the VMware vSphere level (e.g., by cluster).

Any Hyper-V or VMware vCenter component is by default represented in Infrastructure as either a known host or a known VM, and is grouped as such in the inventory. (By default, the Inventory group names are Discovered Hosts and Discovered VM Hosts ). When Elements are ignored, they are removed from Infrastructure. If new hosts or VMs are discovered during Sync/vSync, they are added to the appropriate Infrastructure group.

For more information, see Managing vCenter Inventories in Uptime Infrastructure Monitor.


Virtual System Components and Topological Dependencies

When a Hyper-V host or VMware vCenter server is added to Uptime Infrastructure Monitor, the hierarchical structure of its components is retained (and used in Infrastructure ). Uptime Infrastructure Monitor observes particular monitoring rules to these existing VMware vSphere topologies that supplement the behavior of physical topologies that are defined in Uptime Infrastructure Monitor. (See Topological Dependencies for more information.)

When you define a physical topology or VMware vSphere virtual system topology in a Topological Dependency, the following behaviors are commonly observed:

  • if a topological parent is experiencing downtime, the child Elements in the topology will share the status (i.e., an Element's dependencies will automatically switch to its status)
  • an outage with an Element, whether actual or topological, will initiate a host check on its parent (e.g., a service monitor and its host, or a host and its topological parent)

However, there are behaviors unique to Topological Dependencies based on a VMware vSphere virtual system topology:

  • as VMs migrate, their links to their Hyper-V or ESX hosts is are maintained
  • Uptime Infrastructure Monitor will be aware of power states in the virtual infrastructure, such that parent Elements that are powered down will not spawn alerts with its child Elements (e.g., all of a VMware vCenter servers many ESX servers and VMs)

Virtual System Object Names in Uptime Infrastructure Monitor

When you first add a VMware vCenter virtual system server to Uptime Infrastructure Monitor as an Element, all of its managed VMs or ESX hosts and VMs are automatically added to Uptime Infrastructure Monitor’s monitored inventory. Each of these Elements is configured to sync its display name and host name with values used with the Hyper-V or VMware vSphere Client. The display name is mapped to the Hyper-V or ESX host, or VM object name in the VMware vSphere Clientvirtual system client, and the host name is mapped to its DNS name. During Sync/vSync, any naming changes in vSphere the virtual system are migrated to Uptime Infrastructure Monitor Elements, and as such these names are by default not editable in Uptime Infrastructure Monitor.

If desired, you can manually disable display name and host name syncing with individual Hyper-V or ESX hosts, or VMs, and enter a name that will be used in Uptime Infrastructure Monitor, regardless of what it is on the network or in the VMware vSphere Clientvirtual system client. See ESX Server Element Profiles or , vSphere VM Element Profiles, or Hyper-V VM Element Profiles for more information.

Note that when a VMware vCenter server is added to Uptime Infrastructure Monitor, and there are ESX hosts and VMs that are already part of the Uptime Infrastructure Monitor inventory, these pre-existing Elements’ display names and host names are not synced with vSphere. After adding a VMware vCenter server, if you would like all ESX host and VM names to be updated through vSync, you will have to manually enable the name sync options for each of these Elements.


Virtual System Components and Service Groups

In Uptime Infrastructure Monitor, vSphere service groups exist to allow you to group similar Elements to perform common host checks, not unlike groupings created in the vSphere Client (e.g., a cluster or datacenter). The key difference with vSphere virtual system service groups from regular ones is once established, vSphere virtual system service groups will be managed by the Sync/vSync process. Any changes detected with the VMware vCenter virtual system server’s topology will automatically be reflected in the Uptime Infrastructure Monitor service group.

For information on creating a service group, see Creating Service Groups.