TSCO best practices implementation suggestion when collecting data from both vCenter and the TSCO Gateway Server with collectors on guests

Version 5

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    TrueSight Capacity Optimization


    BMC TrueSight Capacity Optimization 11.3, 11.0, 10.7, 10.5, 10.3, 10.0 ; BMC Capacity Optimization 9.5.02



    In TrueSight Capacity Optimization (TSCO) there are VMware host entities with the same name that initially may appear to be duplicates but one is type Virtual Machine - VMware (from the vCenter ETL) and the other is type Virtual Node - VMware (from the TSCO Agent through the TSCO Gateway Server ETL).


    *** Note this can also occur with Red Hat Enterprise Virtualization - Extractor service. The details provided in this KA also apply for  this data collected from the Red Hat Enterprise Virtualization - Extractor service and TSCO agent through the TSCO Gateway server ETL


    What is the best practices recommendation for how to manage an environment where systems are visible at both the vCenter level and from a BPA collector running within the guest (which is collecting the workloads)?

    When running queries against the Public View (PV) tables in the TSCO database both system entities will be reported up with different CPU Utilization values in the generated report.  This is because the CPU Utilization value is being reported both at the physical VMware level (the "Virtual Machine - VMware" entity) and the in-guest virtual CPU level (the "Virtual Node - VMware" entity).  What is the best practices recommendation on how to best avoid reporting confusion in this type of environment?


    Applies To


    BMC TrueSight Capacity Optimization 11.3, 11.0, 10.7, 10.5, 10.3, 10.0
    BMC Capacity Optimization 9.5, 9.0






    This behavior exists for all virtualization platforms that are supported for data collection both at the Hypervisor level and via an in-guest collector.  So, for example, a "Virtual Machine - Xen" entity is constructed based upon data available at the Xen Hypervisor level (so data collected on the Xen host where the guests reside).  The "Virtual Node - Xen" entity is constructed based upon data available from a collector running within the Virtual guest OS instance itself.  Since the data available from the two different sources represents different things (one is a view at the hypervisor level of the "physical" resource consumption and the other is a view from within the virtual OS instance of its internal view of resource consumption) they are kept separate in TrueSIght Capacity Optimization (TSCO).  Additionally those entities can't be represented together as a single sysid because there is overlap between the metrics available at the different levels (such as CPU_UTIL and MEM_UTIL) and TSCO can't represent those two different streams of overlapping data within the same entity.


    The following recommendations are given in terms of VMware virtualization, but are true for all virtualization types.


    In general the primary recommendations are:

    • Ensure the "Virtual Machine - VMware" systems and "Virtual Node - VMware" systems remain in separate domains in TSCO for reporting
    • When running queries against the Public View (PV) tables, filter the "Virtual Node - VMware" system type out of your query since typically the only time you'd want to be looking at that data is if you were looking at the workloads that system object carried

    Typically for reporting purposes one will want to report on the physical resource consumption of the VMware host or VMware guest entities rather than the in-guest virtual resource consumption values.  This is because the physical level resource utilization reporting available from vCenter will more accurately represent resource consumption than the in-guest OS level view of resource consumption.  The in-guest view is useful for reporting the process or workload level resource consumption breakdown and can be useful for detecting specific in-guest OS level resource constraints (for example, in-guest paging due to the physical memory configuration of the Virtual Machine being too low).


    So, when reporting on VMware entities it is best to always filter by entity type and report the physical resource consumption data separately from the in-guest virtual resource consumption data.


    Q: Can the 'Virtual Machine - VMware' and 'Virtual Node - VMware' entities be reconciled together in TSCO?


    No, one should not reconcile the vCenter Extractor Service and TSOM ETL entities together.  The reason is that both the vCenter Extractor Service and TSOM ETL report overlapping metrics (CPU_UTIL, for example) that are collected from a different data source with a different interpretation.  The vCenter Extractor Service is importing data from vCenter and reports utilization values as vCenter sees utilization and the TSOM ETL is reporting data from within the guest machines and reports information via the 'in-guest' views.

    By default in TSCO the entities will remain separate because they are different entity types (the VMware ETL will report entities of type 'Virtual Machine - VMware' but ETLs reporting data collected from within the guest will report entities of type 'Virtual Node - VMware' or 'Generic' (depending on the entity).

    Legacy ID:KA362506


    Article Number:


    Article Type:

    Solutions to a Product Problem

      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles