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

Upstream bug assigned to ekohlvan

For the moment i have an unoffocial udev rule workaorund in place to rename the VF interface to 'envfX'. I have chosen to use the 'envfX' because it already matched an existing 'en*v*' pattern in Satellite ignore interface patterns list and with that worked out-of-the-box of Satellite.

I created the udev rule based on/etc/udev/rules.d/68-azure-sriov-nm-unmanaged.rules

~~~
$ sudo cat /etc/udev/rules.d/68-azure-sriov-rename-to-envf.rules
SUBSYSTEM=="net", DRIVERS=="hv_pci", ACTION=="add|change|move", NAME="envf$env{IFINDEX}"

[Azure] root@li-lc-2439 ~
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> 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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0d:3a:bb:69:46 brd ff:ff:ff:ff:ff:ff
    inet 10.208.0.119/23 brd 10.208.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: envf3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth0 state UP group default qlen 1000
    link/ether 00:0d:3a:bb:69:46 brd ff:ff:ff:ff:ff:ff
    altname enP36852p0s2

[Azure] root@li-lc-2439 ~
$ sudo dmesg | grep -i env
[    6.436299] mlx5_core 8ff4:00:02.0 envf3: renamed from enP36852s1
[    8.531046] mlx5_core 8ff4:00:02.0 envf3: Link up
[    8.569052] hv_netvsc 000d3abb-6946-000d-3abb-6946000d3abb eth0: Data path switched to VF: envf3
~~~


Can you please check from RedHat side for an official solution for Dv5/AcceleratedNetworking support, maybe the above code to rename to envfX can be made also generic available if it does not cause other disruptions. At least using envfX instead of the enPxsx is for me much more easy to understand, especially that enPxsx is an real interface port name on physical servers

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

I had to provide comments on this BZ because on the Jira issues i am unable to provide comments. If BZ is not going to be used then please also allow user/requester to post comments on the issue.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days