Description of problem: Issue is as described in this thread, https://www.redhat.com/archives/libvir-list/2015-December/msg00683.html Basically at de-allocation of a Mellanox VF, the MAC address should be zeroed-out. Instead there seems to be an issue with the mlx4_core driver which is preventing that action, and the net result is the assigned MAC address stayed tied to the VF, but returned to the pool, significantly raising the risk of a MAC address collision. We have worked around this issue for now by pre-allocating MAC addresses to all VFs, but that is not scalable for our purposes. It would be far better to allow oVirt/libvirt to handle MAC address management on the VFs. Version-Release number of selected component (if applicable): $ modinfo mlx4_core filename: /lib/modules/4.3.4-300.fc23.x86_64/kernel/drivers/net/ethernet/mellanox/mlx4/mlx4_core.ko.xz version: 2.2-1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
also see - https://bugzilla.redhat.com/show_bug.cgi?id=1302166
Did anyone ever address this with the mellanox developers upstream? It seems Moshe was involved in the discussion on the libvirt list, but I've not seen any follow up on the netdev list that I can find. If the behavior of the mlx4 driver needs to change (among other drivers) to zero out the MAC on deallocation, then it needs to be discussed and changed upstream.
I have raised the issue with Mellanox, who say their technical team is looking into the issue. No clue if that will result in something positive, but some friendly pressure from Red Hat would be greatly appreciated.
This was fixed in the 4.5.y rebase with commit 6e52242