enforce fqdn for esx guest hostnames

Hello! My customer has a large ESX env with guests partially having short, partially FQDN hostnames. When intgreting this into OMI we get duplicate CIs. It seems as if fixing this in OMI does not help because attempting to show VPV graphs using the corrected hostname will fail to return any data (since VPV still knows the short guest hostname). So it seems as it the only way (besides changing the actual hostnames of all the wrong guests - which is very risky due to the number and productive state) is to make VPV somehow convert the short hostnames to FQDN. Is that possible and if so how? Or is there any other way to solve this problem? Many thx!!
Parents
  • we rely on the VMware VI-SDK APIs for getting the fqdn/ ip address of guests.

    This works only if VMware tools is running on the guest. and if there's any wrong naming that cannot be fixed.

    there's no other attribute available for reconciliation, unfortunately.

    - RamD

  • Admittedly it's not a simple fix, but in theory HP could - provide a configurable setting "enforce fqdn" or so - whenever querying a hostname from vmware, perform a regular name resolution - store that fqdn in the DB, maybe as additional node attribute Then, the VPV-OMI Integration would need to honor that new attribute if present. Reversely, whenever referencing a node (guest or host) using the VPV API, either the regular hostname (as today) or the additional fqdn can be used to identify the actual object. I agree, that this would be an enhancement for a future version, but I know that other customers have the same problem, so it might be worth it. Thx tge
  • Valid point - dns lookup could be done when elements are published to central model repository.

    the value we get from vCenter is the vision of truth as seen by the tool. we are not dealing with agents here - that leaves us with quite a chance of dns lookup also failing, if only a short name is specified as fqdn wrongly, or even if let's say the VM is on a different network (and separate dns / domains). bottomline - if you got the networking / configuration wrong, it affects the working.

  • Valid point - dns lookup could be done when elements are published to central model repository.

    the value we get from vCenter is the vision of truth as seen by the tool. we are not dealing with agents here - that leaves us with quite a chance of dns lookup also failing, if only a short name is specified as fqdn wrongly, or even if let's say the VM is on a different network (and separate dns / domains). bottomline - if you got the networking / configuration wrong, it affects the working.

  • Valid point - dns lookup could be done when elements are published to central model repository.

    the value we get from vCenter is the vision of truth as seen by the tool. we are not dealing with agents here - that leaves us with quite a chance of dns lookup also failing, if only a short name is specified as fqdn wrongly, or even if let's say the VM is on a different network (and separate dns / domains). bottomline - if you got the networking / configuration wrong, it affects the working.

  • Valid points too, though in the end not helpful: Currently it's just not usable as it is and if nobody will change anything, it never will be. So, here another proposal how to find a solution: Essentially the FQDN could be seen as a hostname alias, so if the VPV DB supported the concept of aliases, which are either automatically determined as suggested initially or manually maintained (the customer can add the FQDN as alias), at least we could get it to work at all. We can extend the short hostnames either before or after the topology import in OMI (and create a consolidated view this way), but what still bites us is the way back, when OMI wants to access VPV with the FQDN, which is unknown there. If now VPV just maps the incoming FQDN (alias) to the actual hostname, all would be fine. Thx!! tge
Reply
  • Valid points too, though in the end not helpful: Currently it's just not usable as it is and if nobody will change anything, it never will be. So, here another proposal how to find a solution: Essentially the FQDN could be seen as a hostname alias, so if the VPV DB supported the concept of aliases, which are either automatically determined as suggested initially or manually maintained (the customer can add the FQDN as alias), at least we could get it to work at all. We can extend the short hostnames either before or after the topology import in OMI (and create a consolidated view this way), but what still bites us is the way back, when OMI wants to access VPV with the FQDN, which is unknown there. If now VPV just maps the incoming FQDN (alias) to the actual hostname, all would be fine. Thx!! tge
Children
No Data