Bug 1476155 - [SR-IOV] - Vdsm doesn't report VFs with zero MAC addresses 00:00:00:00:00:00 - bnx2x driver
[SR-IOV] - Vdsm doesn't report VFs with zero MAC addresses 00:00:00:00:00:00 ...
Status: VERIFIED
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
4.1.0
Unspecified Unspecified
high Severity medium
: ovirt-4.2.0
: ---
Assigned To: Edward Haas
Michael Burman
: Reopened
Depends On: 1474638
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-28 03:35 EDT by Sergio Lopez
Modified: 2017-11-07 02:08 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-13 02:43:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sergio Lopez 2017-07-28 03:35:49 EDT
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 10:21:10 EDT
Dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1474638?
Comment 2 rhev-integ 2017-08-10 13:53:11 EDT
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@redhat.comINFO: 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@redhat.com
Comment 3 Meni Yakove 2017-08-13 02:38:26 EDT
We don't have hardware with bnx2x interfaces.
Comment 4 RHEL Product and Program Management 2017-08-13 02:43:05 EDT
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 12:50:44 EDT
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@redhat.comINFO: 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@redhat.com
Comment 10 Dan Kenigsberg 2017-08-16 02:50:43 EDT
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 07:32:38 EDT
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 02:08:45 EST
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

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