Description of problem: New Dsv5-series /Ev5-series virtual machines on Azure portal with accelerated networking creating a duplicate interface for Satellite clients when using custom rhsm or puppet facts. Version-Release number of selected component (if applicable): Satellite 6.10 Azure series 5 VM How reproducible: Customer Environment Steps to Reproduce: 1. Create a virtual machine with the latest version 5(d2s_v5 or ev5) with accelerated networking and create custom puppet or rhsm network facts. 2. On this VM kernel command line parameter 'net.ifnames=0’ is set. 3. Registering this VM to the Satellite server creates a master and slave interface of the same name i.e. eth1. Actual results: There should not be a duplicate interface for the VM. It should show the interface i.e. eth0 and eth1. Expected results: Showing duplicate interface for the host. # hammer host interface list --host=client.example.com ----|------------|-------------------------------------------|-------------------|------------|------------------------- ID | IDENTIFIER | TYPE | MAC ADDRESS | IP ADDRESS | DNS NAME ----|------------|-------------------------------------------|-------------------|------------|------------------------- 100 | eth1 | interface (primary, provision, execution) | 00:0d:xx:xx:xx:xx | | client.example.com 101 | eth1 | interface Additional info:
I don't think this is easy to properly resolve. There were some private comments with full details, but we can summarize that by saying that there are two NICs (eth0 & eth1) with the same MAC address. Foreman gets confused by that since it has always identified a NIC by MAC. Facter doesn't provide anything about the link type so we lack the information needed to make smart choices. And even if Facter does implement it, we also need others like RHSM to do the same. My short term solution is to detect the conflict: if there are multiple NICs with the same MAC address then refuse to import NIC information. This wouldn't provide any control, but it at least prevents a known bad situation. Regarding notifying the user: it's an automated process, so the best you can do is to log a warning in the production log (/var/log/foreman/production.log by default). We have no mechanism now to signal the user "this host has potential issues". The global notification system is not suited to this since you would either log a message for each host every time a report comes in (usually every 30 minutes with Puppet) and overload the user or only notify once which the user will forget.
I understand that it is hard for satellite to distuinishg this situation when the provided facts from the various source systems (rhsm, puppet, ansinble) are lacking the additional interface information like if it is a slave. And to get this informatation added in all facts source systems (rhsm,puppet,ansbible) and an official release available then we are easily 2-years later. For this reason i already proposed in the case if an alternative is possible: Is it possible to have a udev rule for the special vif slave interface to rename it to a special name like 'envifXX' and then in satellite the 'envif*' can be added to the interface ignore list.
I think an udev rule could certainly be a valid workaround, but it's not something that we can easily provide to all customers. I've written a simple proof of concept that I have yet to test. https://github.com/theforeman/foreman/pull/9761 aims to solve it for all fact sources by handling it in the base fact parser class. I'll see if I can verify that concept works.
Upstream bug assigned to ekohlvan