Bug 1476155 - [SR-IOV] - Vdsm doesn't report VFs with zero MAC addresses 00:00:00:00:00:00 - bnx2x driver
Summary: [SR-IOV] - Vdsm doesn't report VFs with zero MAC addresses 00:00:00:00:00:00 ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ovirt-4.2.0
: ---
Assignee: Edward Haas
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1474638
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-28 07:35 UTC by Sergio Lopez
Modified: 2021-05-01 16:49 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-05-15 17:51:57 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:1489 0 None None None 2018-05-15 17:53:24 UTC

Description Sergio Lopez 2017-07-28 07:35:49 UTC
vdsm hides VFs with default MAC address "00:00:00:00:00:00":

<snip from "lib/vdsm/network/ipwrapper.py:222">
    def _isVFhidden(self):
        if self.address == '00:00:00:00:00:00':
            return True
        # We hide a VF if there exists a macvtap device with the same address.
        # We assume that such VFs are used by a VM and should not be reported
        # as host nics
        for path in iglob('/sys/class/net/*/address'):
            dev = os.path.basename(os.path.dirname(path))
            if (dev != self.name and _read_stripped(path) == self.address and
                    self._detectType(dev) == LinkType.MACVLAN):
                return True
        return False
</snip>

This comes all the way back since explicit detection of VFs was introduced in 46a8b3ef4c1a09409817627dde886c2f6d127861, and is still present in master as of today (July 28).

Apparently, this doesn't affect igb and ixgbe because we're explicitly setting a different MAC to work around another bug:

<snip from "lib/vdsm/network/link/sriov.py:61">
def _set_valid_vf_macs(pci_path, numvfs):
    """
        some drivers forbid resetting VF MAC address back to 00:00:00:00:00:00,
        which was its original value. By setting the MAC addresses to a valid
        value, upon restoration the valid address will be accepted.

        The drivers and their BZ's:
        1) igb: https://bugzilla.redhat.com/1341248
        2) ixgbe: https://bugzilla.redhat.com/1415609

        Once resolved, this method and its accompanying methods should
        be removed.
    """
    if _is_zeromac_limited_driver(pci_path):
        _modify_mac_addresses(pci_path, numvfs)


def _is_zeromac_limited_driver(pci_path):
    ZEROMAC_LIMITED_DRIVERS = ('igb',
                               'ixgbe',)

    for driver in ZEROMAC_LIMITED_DRIVERS:
        driver_path = DRIVERS_PATH + driver

        if (os.path.exists(driver_path) and
                pci_path in os.listdir(driver_path)):
                    return True

    return False


def _modify_mac_addresses(pci_path, numvfs):
    TARGET_MAC = '02:00:00:00:00:01'

    pf = os.listdir('/sys/bus/pci/devices/{}/net/'.format(pci_path))[0]
    for vf_num in range(numvfs):
        iface.set_mac_address(pf, TARGET_MAC, vf_num=vf_num)
</snip>

With a bnx2x device, VFs keep '00:00:00:00:00:00' as MAC address, and thus are not presented by VDSM to RHV-M, so they can't be used by VM passthrough.

Comment 1 Ian Pilcher 2017-08-01 14:21:10 UTC
Dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1474638?

Comment 2 rhev-integ 2017-08-10 17:53:11 UTC
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ]

For more info please contact: rhv-devops

Comment 3 Meni Yakove 2017-08-13 06:38:26 UTC
We don't have hardware with bnx2x interfaces.

Comment 4 RHEL Program Management 2017-08-13 06:43:05 UTC
Quality Engineering Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 9 rhev-integ 2017-08-15 16:50:44 UTC
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ]

For more info please contact: rhv-devops

Comment 10 Dan Kenigsberg 2017-08-16 06:50:43 UTC
I'd be skipping z-stream cloning because we already have bug 1474638 to track this issue in 4.1.

Comment 13 Dan Kenigsberg 2017-09-24 11:32:38 UTC
Edy, unfortunately, downstream bugs - particularly those with customer tickets - must not be move manually to ON_QA. Only the Errata tool should do this, to make sure they are properly communicated to customers.

Comment 15 Michael Burman 2017-11-07 07:08:45 UTC
Verified on - vdsm-4.20.6-1.el7ev.x86_64 with:

Dell PowerEdge FC430
Ethernet controller: Broadcom Limited NetXtreme II BCM57810 10 Gigabit Ethernet Virtual Function
Kernel driver in use: bnx2x
        Kernel modules: bnx2x

ethtool -i enp1s10f5
driver: bnx2x

enp1s10f5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop portid f8cab8911c18 state DOWN mode DEFAULT qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Comment 16 RHV bug bot 2017-12-06 16:18:48 UTC
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No relevant external trackers attached]

For more info please contact: rhv-devops

Comment 17 RHV bug bot 2017-12-12 21:17:05 UTC
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[No relevant external trackers attached]

For more info please contact: rhv-devops

Comment 18 RHV bug bot 2017-12-18 17:06:35 UTC
INFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[No relevant external trackers attached]

For more info please contact: rhv-devops

Comment 23 errata-xmlrpc 2018-05-15 17:51:57 UTC
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, 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/RHEA-2018:1489

Comment 24 Franta Kust 2019-05-16 13:04:17 UTC
BZ<2>Jira Resync


Note You need to log in before you can comment on or make changes to this bug.