# Multiple Interfaces vCenter Monitoring **URL:** \ **Category:** Installation & Configuration\ **Created:** [December 14, 2020, 2:21pm UTC](https://forum.opennebula.io/t/multiple-interfaces-vcenter-monitoring/9054 "2020-12-14T14:21:19Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ben\_McGuire](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/ben_mcguire/32/5544_2.png) [@Ben\_McGuire](https://forum.opennebula.io/u/Ben_McGuire)\ **Post date:** [December 14, 2020, 2:21pm UTC](https://forum.opennebula.io/t/multiple-interfaces-vcenter-monitoring/9054/1 "2020-12-14T14:21:19Z")
We have 2 network interfaces connected to our One Dashboard as our vSphere server is on a different private subnet to our external facing NAT interface. As I have posted multiple times about the network monitoring not working I thought further info would be good. I am a it lost in regards to the configurating files. There are multiple locations such as:- /etc/one /usr/share/one Which one do we use? In addition, as we are using multiple nics in One will it know to use the correct interface to send monitoring data from vSphere ? Currently the monitoring config file has 0.0.0.0 which means it lets One work it out. Does vSPhere use this ? What is concerning is the oned.log specifically to hook errors. Mon Dec 14 14:22:37 2020 [Z0][VMM][D]: Message received: LOG I 65 Successfully execute network driver operation: post.$ $ Mon Dec 14 14:22:37 2020 [Z0][VMM][D]: Message received: DEPLOY SUCCESS 65 vm-809$ $ Mon Dec 14 14:22:37 2020 [Z0][HKM][D]: Message received: EXECUTE FAILURE 9 1 PEFSR1VNRU5UUz4kSUQgJFBSRVZfU1RBVEUgJFBSRVZfTENNX1NUQVRFIDwvQVJHVU1FTlRTPjxFWEVDVVRJT05fUkVTVUxUPjxDT01NQU5EPi91c3IvbGliL29uZS9pb25lL2hvb2tzL3ZjZW50ZXIvc2V0X2xpbWl0cy5yYiAkSUQgJFBSRVZfU1RBVEUgJFBSRVZfTENNX1NUQVRFIDwvQ09NTUFORD48U1RET1VUPjwvU1RET1VUPjxTVERFUlI+TDNWemNpOXphR0Z5WlM5eWRXSjVaMlZ0Y3k5eWRXSjVaMlZ0Y3k5amIzSmxYMlY0ZEM5clpYSnVaV3hmCmNtVnhkV2x5WlM1eVlqbzFPVHBwYmlCZ2NtVnhkV2x5WlNjNklHTmhibTV2ZENCc2IyRmtJSE4xWTJnZwpabWxzWlNBdExTQXZkWE55TDJ4cFlpOXZibVV2YzNWdWMzUnZibVV2WkdWaWRXZGZiR2xpTG5KaUlDaE0KYjJGa1JYSnliM0lwQ2dsbWNtOXRJQzkxYzNJdmMyaGhjbVV2Y25WaWVXZGxiWE12Y25WaWVXZGxiWE12ClkyOXlaVjlsZUhRdmEyVnlibVZzWDNKbGNYVnBjbVV1Y21JNk5UazZhVzRnWUhKbGNYVnBjbVVuQ2dsbQpjbTl0SUM5MWMzSXZiR2xpTDI5dVpTOXBiMjVsTDJodmIydHpMM1pqWlc1MFpYSXZjMlYwWDJ4cGJXbDAKY3k1eVlqbzBOanBwYmlCZ1lteHZZMnNnYVc0Z1BHMWhhVzQrSndvSlpuSnZiU0F2ZFhOeUwyeHBZaTl2CmJtVXZhVzl1WlM5b2IyOXJjeTkyWTJWdWRHVnlMM05sZEY5c2FXMXBkSE11Y21JNk5EQTZhVzRnWUhOMQpjSEJ5WlhOelgyOTFkSEIxZENjS0NXWnliMjBnTDNWemNpOXNhV0l2YjI1bEwybHZibVV2YUc5dmEzTXYKZG1ObGJuUmxjaTl6WlhSZmJHbHRhWFJ6TG5KaU9qUTJPbWx1SUdBOGJXRnBiajRuQ2c9PQo8L1NUREVSUj48Q09ERT4xPC9DT0RFPjwvRVhFQ1VUSU9OX1JFU1VMVD4=$ $ Mon Dec 14 14:22:37 2020 [Z0][HKM][E]: Error executing Hook 9$ Mon Dec 14 14:22:37 2020 [Z0][HKM][D]: Message received: EXECUTE FAILURE 4 1 PEFSR1VNRU5UUz4kSUQgPC9BUkdVTUVOVFM+PEVYRUNVVElPTl9SRVNVTFQ+PENPTU1BTkQ+L3Vzci9saWIvb25lL2lvbmUvaG9va3MvcmVjb3JkLnJiICRJRCA8L0NPTU1BTkQ+PFNURE9VVD48L1NURE9VVD48U1RERVJSPkwzVnpjaTl6YUdGeVpTOW5aVzF6TDJkbGJYTXZiWGx6Y1d3eUxUQXVOUzR6TDJ4cFlpOXRlWE54YkRJdgpZMnhwWlc1MExuSmlPakV6TVRwcGJpQmdYM0YxWlhKNUp6b2dUWGx6Y1d3eU9qcEZjbkp2Y2pvZ1EyOXMKZFcxdUlDZHBaQ2NnWTJGdWJtOTBJR0psSUc1MWJHd2dLRk5sY1hWbGJEbzZUbTkwVG5Wc2JFTnZibk4wCmNtRnBiblJXYVc5c1lYUnBiMjRwQ2dsbWNtOXRJQzkxYzNJdmMyaGhjbVV2WjJWdGN5OW5aVzF6TDIxNQpjM0ZzTWkwd0xqVXVNeTlzYVdJdmJYbHpjV3d5TDJOc2FXVnVkQzV5WWpveE16RTZhVzRnWUdKc2IyTnIKSUdsdUlIRjFaWEo1SndvSlpuSnZiU0F2ZFhOeUwzTm9ZWEpsTDJkbGJYTXZaMlZ0Y3k5dGVYTnhiREl0Ck1DNDFMak12YkdsaUwyMTVjM0ZzTWk5amJHbGxiblF1Y21JNk1UTXdPbWx1SUdCb1lXNWtiR1ZmYVc1MApaWEp5ZFhCMEp3b0pabkp2YlNBdmRYTnlMM05vWVhKbEwyZGxiWE12WjJWdGN5OXRlWE54YkRJdE1DNDEKTGpNdmJHbGlMMjE1YzNGc01pOWpiR2xsYm5RdWNtSTZNVE13T21sdUlHQnhkV1Z5ZVNjS0NXWnliMjBnCkwzVnpjaTl6YUdGeVpTOW5aVzF6TDJkbGJYTXZjMlZ4ZFdWc0xUVXVNekV1TUM5c2FXSXZjMlZ4ZFdWcwpMMkZrWVhCMFpYSnpMMjE1YzNGc01pNXlZam94TXpZNmFXNGdZR0pzYjJOcklHbHVJRjlsZUdWamRYUmwKSndvSlpuSnZiU0F2ZFhOeUwzTm9ZWEpsTDJkbGJYTXZaMlZ0Y3k5elpYRjFaV3d0TlM0ek1TNHdMMnhwCllpOXpaWEYxWld3dlpHRjBZV0poYzJVdmJHOW5aMmx1Wnk1eVlqb3pPRHBwYmlCZ2JHOW5YMk52Ym01bApZM1JwYjI1ZmVXbGxiR1FuQ2dsbWNtOXRJQzkxYzNJdmMyaGhjbVV2WjJWdGN5OW5aVzF6TDNObGNYVmwKYkMwMUxqTXhMakF2YkdsaUwzTmxjWFZsYkM5aFpHRndkR1Z5Y3k5dGVYTnhiREl1Y21JNk1UTXhPbWx1CklHQmZaWGhsWTNWMFpTY0tDV1p5YjIwZ0wzVnpjaTl6YUdGeVpTOW5aVzF6TDJkbGJYTXZjMlZ4ZFdWcwpMVFV1TXpFdU1DOXNhV0l2YzJWeGRXVnNMMkZrWVhCMFpYSnpMM1YwYVd4ekwyMTVjM0ZzWDIxNWMzRnMKTWk1eVlqb3pPVHBwYmlCZ1lteHZZMnNnYVc0Z1pYaGxZM1YwWlNjS0NXWnliMjBnTDNWemNpOXphR0Z5ClpTOW5aVzF6TDJkbGJYTXZjMlZ4ZFdWc0xUVXVNekV1TUM5c2FXSXZjMlZ4ZFdWc0wyTnZibTVsWTNScApiMjVmY0c5dmJDOTBhSEpsWVdSbFpDNXlZam81TWpwcGJpQmdhRzlzWkNjS0NXWnliMjBnTDNWemNpOXoKYUdGeVpTOW5aVzF6TDJkbGJYTXZjMlZ4ZFdWc0xUVXVNekV1TUM5c2FXSXZjMlZ4ZFdWc0wyUmhkR0ZpCllYTmxMMk52Ym01bFkzUnBibWN1Y21JNk1qY3dPbWx1SUdCemVXNWphSEp2Ym1sNlpTY0tDV1p5YjIwZwpMM1Z6Y2k5emFHRnlaUzluWlcxekwyZGxiWE12YzJWeGRXVnNMVFV1TXpFdU1DOXNhV0l2YzJWeGRXVnMKTDJGa1lYQjBaWEp6TDNWMGFXeHpMMjE1YzNGc1gyMTVjM0ZzTWk1eVlqb3pPVHBwYmlCZ1pYaGxZM1YwClpTY0tDV1p5YjIwZ0wzVnpjaTl6YUdGeVpTOW5aVzF6TDJkbGJYTXZjMlZ4ZFdWc0xUVXVNekV1TUM5cwphV0l2YzJWeGRXVnNMMkZrWVhCMFpYSnpMMjE1YzNGc01pNXlZam8zTVRwcGJpQmdaWGhsWTNWMFpWOXAKYm5ObGNuUW5DZ2xtY205dElDOTFjM0l2YzJoaGNtVXZaMlZ0Y3k5blpXMXpMM05sY1hWbGJDMDFMak14CkxqQXZiR2xpTDNObGNYVmxiQzlrWVhSaGMyVjBMMkZqZEdsdmJuTXVjbUk2TVRFd05UcHBiaUJnWlhobApZM1YwWlY5cGJuTmxjblFuQ2dsbWNtOXRJQzkxYzNJdmMyaGhjbVV2WjJWdGN5OW5aVzF6TDNObGNYVmwKYkMwMUxqTXhMakF2YkdsaUwzTmxjWFZsYkM5a1lYUmhjMlYwTDJGamRHbHZibk11Y21JNk5EQXhPbWx1CklHQnBibk5sY25RbkNnbG1jbTl0SUM5MWMzSXZiR2xpTDI5dVpTOXBiMjVsTDJodmIydHpMM0psWTI5eQpaQzV5WWpvMk1EcHBiaUJnUEcxaGFXNCtKd289CjwvU1RERVJSPjxDT0RFPjE8L0NPREU+PC9FWEVDVVRJT05fUkVTVUxUPg==$ Also there doesnt seems to be any NETRX or TX info. The CPU, Disk and Memory graphs are populating just not the network stuff. Any guidance would be appreciated. ---
**Author:** ![atodorov\_storpool](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/atodorov_storpool/32/5327_2.png) [@atodorov\_storpool](https://forum.opennebula.io/u/atodorov_storpool)\ **Post date:** [December 14, 2020, 2:46pm UTC](https://forum.opennebula.io/t/multiple-interfaces-vcenter-monitoring/9054/2 "2020-12-14T14:46:17Z")
Hi @Ben_McGuire, The opennebula configuration is in `/etc/one` and `/var/lib/one/remotes/etc`. Files from other places should be used as references only. In your case you should take a look for the NETWORK configuration at `/etc/one/monitord.conf`. It would be best if you try setting `MONITOR_ADDRESS` to the IP address configured on the fe where the monitoring data is expected to be received. Best Regards, Anton Todorov ---
**Author:** ![Ben\_McGuire](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/ben_mcguire/32/5544_2.png) [@Ben\_McGuire](https://forum.opennebula.io/u/Ben_McGuire)\ **Post date:** [December 15, 2020, 3:39pm UTC](https://forum.opennebula.io/t/multiple-interfaces-vcenter-monitoring/9054/3 "2020-12-15T15:39:49Z")
Hi @atodorov_storpool Thank you for the information. I have added the interface address which is on the same subnet as vSphere however no traffic is ever displayed in Sunstone. I am a little confused about the settings as there are 2 different ones as per below. NETWORK = [ ADDRESS = “0.0.0.0”, MONITOR\_ADDRESS = “auto”, PORT = 4124, THREADS = 8, PUBKEY = “”, PRIKEY = “” Am a correct in saying vSphere DOES NOT send logs using the above port as from what I know this setting is for KVM hosts and NOT vSphere ? Also, as many config settings use ‘localhost’ should I add the vSphere subnet to localhost also ? I have pasted the vNic setup bearing in mind 192 is the Sunstone vNic which uses NAT and 172 vNic is using the same VDS port group as vSphere. ``` [root@cloud one]# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:86:d9:50 brd ff:ff:ff:ff:ff:ff inet 192.168.1.70/24 brd 192.168.1.255 scope global noprefixroute ens192 valid_lft forever preferred_lft forever inet6 fe80::49c2:5c18:be31:e8bd/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: ens224: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:86:1f:5b brd ff:ff:ff:ff:ff:ff inet 172.16.0.240/12 brd 172.31.255.255 scope global noprefixroute ens224 valid_lft forever preferred_lft forever inet6 fe80::dac4:18f4:6a21:b50b/64 scope link noprefixroute valid_lft forever preferred_lft forever ``` It may be prudent for the Opennebula guys to provide some further advice on the proper VDS port policies for imported VDS port groups. Currently only forged transmits are accepted as there is something in the docs about standard switches needing this but still no network traffic ever displays in Sunstone even though CPU and Memory which is weird. 🙂 ---
**Author:** ![Ben\_McGuire](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/ben_mcguire/32/5544_2.png) [@Ben\_McGuire](https://forum.opennebula.io/u/Ben_McGuire)\ **Post date:** [February 4, 2021, 3:03pm UTC](https://forum.opennebula.io/t/multiple-interfaces-vcenter-monitoring/9054/4 "2021-02-04T15:03:44Z")
Just to provide an update to others. We had initially created a dedicated user in vSphere for Opennebula and it seems we did not give the user the appropriate permissions. Now we created Opennebula user in vCenter and given assigned it part of the Administrators group and now network monitoring is working. 🙂