TrueSight Capacity Optimization - In TSCO too many duplicate entities in the workspace with different UUID

Version 3
    Share This:

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


    PRODUCT:

    TrueSight Capacity Optimization


    APPLIES TO:

    BMC Capacity Optimization



    PROBLEM:

     

    I questioned the vCenter admins and found that in Development they will destroy and rebuild vms with the same name. This week it might be linux and next week it might be windows.

    But the big issue is that the virtual machine will be killed and rebuilt multiple times in different configuration and with a different UUID.

    So do we need to be worried about a bunch of entries in Newly Discovered and Unassigned? It seems that it must become unassigned when the virtual machine is killed. And then it shows up again with a new UUID.



    LP: BMC Capacity Optimization 9.0.03
    DR: Capacity Optimization 9.0.03


    Issue Summary: How to get vCenter ETL data out of "Newly discovered" into All Domains where it belongs.

     

     


    SOLUTION:

     

    Q. So do we need to be worried about a bunch of entries in Newly Discovered and Unassigned?

    A. No, you don't need to worry about entities showing up in 'Newly Discovered' or 'Unassigned' if they are retired VMware guest objects. An entity ends up in 'Unassigned' when it is no longer associated with a current domain hierarchy in the workspace. So, when VMware guest X (where X is a unique UUID) is retired it will fall out of the VMware domain hierarchy and end up in Unassigned. If the host is newly created and then retired quickly it will end up in 'Newly Discovered' instead (since 'Newly Discovered' systems are basically 'Unassigned' systems that were newly imported into BCO for the first time).

    Q. Do I need to change the "Compatibility lookup names customization" in the VMware ETL configuration away from the default setting? If I do go away from this setting, what are the ramifications?

    No, I think the current behavior of BCO is correct. The UUID uniquely identifies the system and these really are different systems (they just happen to have the same hostname). What BCO is doing right now seems like the best behavior -- create a new entity for each new system object that is created. If you changed the 'Compatibility Lookup' then you'd end up re-using the same BCO system entity ID across each re-use of the hostname. Since you said that these systems change each time (so the hostname isn't really uniquely identify a host -- it is just a tag associated to an object while it exists) you'd end up with a crazy hodgepodge of configurations over time for that system entity.

    A. So, BCO is doing the right things. Yes, you are going to end up with a bunch of systems showing up in the 'Unassigned' list -- but after 30 days of inactivity they will disappear from that list. This might have an impact on some of your VMware reporting (not sure) since you'll have a bunch of systems using the same name over a 30 day period so they will each get their own row on the report (and it might be hard to tell them apart). Although it is expected for this type of dynamic system creation/destruction , they don't really care about guest level reporting in that VMware environment and will be focused on ESX host or cluster level reporting and thus this duplication will be a non-issue for them in relation to the BCO reports and views.

      
    Related Products:  
       
    1. BMC Capacity Optimization

     


    Article Number:

    000294656


    Article Type:

    Solutions to a Product Problem



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