Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The SR-IOV representors are special interfaces associated with PF device and represent VF devices created on this PF. The representors have specific format of phys_port_name attribute: pf<X>vf<Y>. This value identifies representor for Y-th VF created on X-th PF of certain device. The current version of systemd (udevd) simply appends value of phys_port_name to interface name of associated PF device.
E.g.:
Lets PF interface is enp129s0f0 and 1 VF created over that PF. Then the interface associated with VF is named enp129s0f0v0 and representor should get interface name enp129s0f0pf0vf0 but because such name is 16 chars long and this is longer than value allowed by the kernel (IFNAMSIZ) then primary interface name for representor remains generic (e.g. eth0, eth1...). For userspace scripts is hard to distinguish what representor interface is associated with particular VF device on certain PF device.
Recent upstream PR (https://github.com/systemd/systemd/pull/28118) introduced a change so representor interface names are composed from name of PF device and 'r<N>' suffix similar to VF interface names:
E.g.
PF device interface is enp129s0f0
VF 0 device interface is enp129s0f0v0
VF 0 representor interface is enp129s0f0r0
So it is easy to find representor interface for n-th VF device on particular PF device.
Version-Release number of selected component (if applicable):
252-15.el9
How reproducible:
100%
Steps to Reproduce:
1. Set eswitch mode in SR-IOV capable NIC to switchdev mode using devlink
E.g. devlink dev eswitch set pci/0000:81:00.0 mode switchdev
2. Create one or more VFs on the particular NIC PF
3. Check VF representor interface names
Actual results:
See above in description
Expected results:
See above in description
Additional info:
The feature has been merged into upstream by PR:
https://github.com/systemd/systemd/pull/28118
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (systemd bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:6640