VMWare Importer: The rule for selecting the primary interface on VMs is not correct
Description
Acceptance / Success Criteria
Lucidchart Diagrams
Activity
Mark Mahacek February 5, 2018 at 9:58 PM
Long term, I will be moving my virtual iSCSI interfaces over to RDM, which would remedy the issue in my scenario. It would be nice to have a workaround with the FQDN as in . For the record, Mattermost user @kcas reported this issue today with their Docker bridge interfaces. I see it being helpful to users if there was a note in the VMware Provisioning documentation that informed users of this IP order caveat until a solution is determined.
Thanks.
Ronny Trommer February 5, 2018 at 9:35 PM
We have several this kind of issues. There is a conceptional problem in the VMware importer:
The provisioning adapter tries to detect reachable interfaces during the import.
The logic how interfaces are imported are hard coded in the provisioning adapter
This logic should probably moved out of the provisioning adapter and into detectors
It should be ensured the IP policies work correctly with the VMware provisioning adapter
is the original author maybe he has some input as well.
Related to issue https://issues.opennms.org/browse/NMS-6140 regarding ESX hosts
Imported VMs appear to use the lowest IP address as the primary. This prevents some VMs with multiple IP addresses from being polled correctly. Specifically, this issue has been seen where the secondary IPs are on iSCSI VLANs that are not routable.
Example VM:
Data IP: 10.100.100.50 (Reported as IP via VMware Tools)
iSCSI IP: 10.100.50.50
Since the iSCSI IP comes first, provisiond is setting this IP as primary in the requisition, however it is not reachable.