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.
Dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1474638?
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
We don't have hardware with bnx2x interfaces.
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
I'd be skipping z-stream cloning because we already have bug 1474638 to track this issue in 4.1.
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.
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
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
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
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
BZ<2>Jira Resync