Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Probe: Hypervisor Redundancy Checks Probe (Virtual Infra)

Purpose

Detect hypervisor redundancy.

Source Processors
Hypervisor and connected leaf (generic graph)

output stage: hypervisor_and_leaf (text set) (generated from graph)

Hypervisor pnic and vnet (generic graph collector)

output stage: hypervisor_pnic_vnet (text set) (generated from graph)

Additional Processor(s)
Hypervisor and leaf count (set count)

input stage: hypervisor_and_leaf

output stage: hypervisors_leaf_count (number set)

Hypervisor vnet pnic count (set count)

input stage: hypervisors_pnic_vnet

output stage: hypervisors_vnet_pnic_count (number set)

Hypervisor without ToR Switch redundancy (range)

input stage: hypervisors_leaf_count

output stage: hypervisor_single_leaf_anomaly (discrete state set)

Networks without link redundancy (range)

input stage: hypervisors_vnet_pnic_count

output stage: hypervisor_vnet_single_pnic_anomaly (discrete state set)

Example Usage

NSX-T Integration - an anomaly is raised in cases without redundancy or a single point of failure (SPOF) in hypervisor connectivity. Examples include:

  • NSX-T transport nodes with a single non-LAG uplink towards ToR leaf devices in the fabric can result in a single point of failure (SPOF) for overlay traffic.
  • NSX-T transport nodes with a single LAG uplink with both members going to a single ToR leaf can result in a single point of failure (SPOF).
  • Lack of redundancy between fabric LAG dual-leaf devices and ESXi hosts.

For more information about this probe, from the blueprint, navigate to Analytics > Probes, click Create Probe, then select Instantiate Predefined Probe from the drop-down list. Select the probe from the Predefined Probe drop-down list to see details specific to the probe.