vmware

Take selectedVnic into account

                     <VirtualNicManagerNetConfig xsi:type="VirtualNicManagerNetConfig">
                        <nicType>management</nicType>
                        <multiSelectAllowed>true</multiSelectAllowed>
                        <candidateVnic>
                            <device>vmk1</device>
                            <key>management.key-vim.host.VirtualNic-vmk1</key>
                            <portgroup></portgroup>
                            <spec>
                                <ip>
                                    <dhcp>false</dhcp>
                                    <ipAddress>10.15.78.214</ipAddress>
                                    <subnetMask>255.255.255.0</subnetMask>
                                </ip>
                                <mac>00:50:56:61:35:15</mac>
                                <distributedVirtualPort>
                                    <switchUuid>50 32 8e 52 37 51 79 08-2d f8 04 ae d0 33 01 fe</switchUuid>
                                    <portgroupKey>dvportgroup-68603</portgroupKey>
                                    <portKey>1488</portKey>
                                    <connectionCookie>451620923</connectionCookie>
                                </distributedVirtualPort>
                                <mtu>9000</mtu>
                                <tsoEnabled>true</tsoEnabled>
                            </spec>
                        </candidateVnic>
                        <candidateVnic>
                            <device>vmk2</device>
                            <key>management.key-vim.host.VirtualNic-vmk2</key>
                            <portgroup></portgroup>
                            <spec>
                                <ip>
                                    <dhcp>false</dhcp>
                                    <ipAddress>10.15.86.214</ipAddress>
                                    <subnetMask>255.255.255.0</subnetMask>
                                </ip>
                                <mac>00:50:56:68:06:d1</mac>
                                <distributedVirtualPort>
                                    <switchUuid>50 32 8e 52 37 51 79 08-2d f8 04 ae d0 33 01 fe</switchUuid>
                                    <portgroupKey>dvportgroup-68605</portgroupKey>
                                    <portKey>1752</portKey>
                                    <connectionCookie>723950379</connectionCookie>
                                </distributedVirtualPort>
                                <mtu>9000</mtu>
                                <tsoEnabled>true</tsoEnabled>
                            </spec>
                        </candidateVnic>
                        <candidateVnic>
                            <device>vmk0</device>
                            <key>management.key-vim.host.VirtualNic-vmk0</key>
                            <portgroup></portgroup>
                            <spec>
                                <ip>
                                    <dhcp>false</dhcp>
                                    <ipAddress>10.79.64.214</ipAddress>
                                    <subnetMask>255.255.255.0</subnetMask>
                                </ip>
                                <mac>0c:c4:7a:d2:f4:3e</mac>
                                <distributedVirtualPort>
                                    <switchUuid>50 32 8e 52 37 51 79 08-2d f8 04 ae d0 33 01 fe</switchUuid>
                                    <portgroupKey>dvportgroup-4830</portgroupKey>
                                    <portKey>423</portKey>
                                    <connectionCookie>1248203149</connectionCookie>
                                </distributedVirtualPort>
                                <mtu>9000</mtu>
                                <tsoEnabled>true</tsoEnabled>
                            </spec>
                        </candidateVnic>
                        <selectedVnic>management.key-vim.host.VirtualNic-vmk0</selectedVnic>
                    </VirtualNicManagerNetConfig>

Available in:

• 5.4.3rc1 113357bbb85
• 6.0.0alpha1(master) ccd3274aeb3

in my particular case, this would probably not solve the problem. The MGMT interface is not reachable via Zabbix, only ESXi Hosts in between them can communicate with the MGMT vmkernel port.

Would there be an option to use HV.DNS for the FQDN of the host?

Curious idea. You can create a new ZBXNEXT.
By the way - how to distinguish fqdn from internal name for any hv ?

Or you can change the template only:

Michael,

this worked. When changing the Prototype to HV.NAME it actually populated the FQDN. Nice! Thanks

Thanks for the fix!

MVekslers Last Friday we finally upgraded from 5.2.7 to 5.4.7 (yay!), and I was looking forward to see this fixed, but sadly we are still affected by this bug. Should we re-open this, or create a new issue?

Background: VMware vCenter 7.0.2 vSAN Cluster with three nodes. Only Node 1 has this problem after LLD discovery: (Tested on 5.4.7 and a 6.0.0alpha6 appliance)

I would expect 192.168.122.181 there, instead of the IP of the vmk3 adapter, which works for Node 2 & 3.

starko Be so kind show the  xml  with config.virtualNicManagerInfo.netConfig response for the problematic HV.

We will show this xml in

... vmware_service_get_hv_data() SOAP response: ... 

in debug level = 5 for "vmware collector"

starko  - I want to look at VirtualNicManagerNetConfig as in example above for the problematic HV.

MVekslers I got the XML data, any way I can sent you in private, instead of posting here public?

I guess I found a hint, for the one not working, the XML states:
    <selectedVnic>management.key-vim.host.VirtualNic-vmk0</selectedVnic>
    <selectedVnic>management.key-vim.host.VirtualNic-vmk3</selectedVnic>
For the two others it's:
    <selectedVnic>management.key-vim.host.VirtualNic-vmk0</selectedVnic>
    <selectedVnic>management.key-vim.host.VirtualNic-vmk3</selectedVnic>

XML response was transferred and received by Zabbix. Public communication may continue here.

starko  What are the main criteria of main (management) interface in your case ?

What's the difference between vmk0 and vmk3? 

starko  Be so kind send me the result of vmware-hv-netinfo.sh execution.

I am interested in the values of key summary.runtime.networkRuntimeInfo.netStackInstanceRuntimeInfo

I hope the result will help as understand the which interface is main.

I will answer as soon as possible MVekslers, but our VMware administrator is not in the office today, and I'm not qualified to answer your questions, and it doesn't make sense if I post my assumptions here. I expect to answer you tomorrow evening. I will take a look at the script. Where do i execute it? From my client against vCenter? Or on ESX itself?

The script have to execute  against vCenter.

I submitted the requested data regarding vmware-hv-netinfo.sh in private.

Regarding your other questions, I have to consult our VMware administrator.

Did not help...

starko  Be so kind, replace in the script 

<urn:pathSet>summary.runtime.networkRuntimeInfo.netStackInstanceRuntimeInfo</urn:pathSet> 

to

<urn:pathSet>config.network</urn:pathSet> 

and send me xml response

starko  What ip of vCenter ?

I just send you the result of the altered script and the vCenter IP.

MVekslers I had a long talk to our VMware Administrator. According to him, the error is more on our, than on Zabbix side. Let me explain in detail:

1. He thinks I reported the "bug" incorrectly. In his opinion, the problem is not that you discover the wrong interface, but that you discover a random management interface.
2. There is no primary/secondary or first/second management interface. They are all the same and equal. He thinks that your questions regarding characteristic to differentiate between the two, are not going to work, as they are equal.
3. We have three conclusions to offer:
   1. We keep it as it is, and we have to make it possible, that Zabbix proxy can reach each management interface, regardless of which Zabbix proxy discovers. (I don't like that, as it ignores the problem completely.)
   2. Zabbix has to make it possible, that Zabbix proxy can discover more than one management interface (=each management interface), because the assumption, that there can either be just one management interface, or that there must be a primary interface, is wrong. There can be multiple management interfaces, and they are all equal. Which would mean, that the current semi-random discovery is the main issue we are talking about.
   3. If would ask us, and only us, because it could be wrong for others, we might say that:
      1. The interface with the lowest VMKx number is the right one (vmk0 > vmk3).
      2. Or that the interface, that shares the IP-subnet with the vCenter IP, is the correct one.

Please tell me your thoughts.

I think about two steps possibility:

• prefer IP which shares the IP-subnet with the vCenter IP
• prefer IP from IP-subnet with default gateway

I talked with our VMware admin, he says that the second idea with the default gateway is very good. In his opinion, only one of the mgmt interfaces will (and should) have a default gateway set. (as far as we know)

So it's either the interface, with the default gateway configured and/or the interface, that shares the IP-subnet with the gateway. Both sound great!

Moved the problem and decision to ZBX-20246