Is there a...hookscript...to assign the hookscript automatically when I create a new LXC or VM? I'm totally going to forget about this later when I'm messing around and adding more to my server.
[SOLVED] communication issue between SRIOV VM VF and CT on PF bridge
- Thread starter ctr
- Start date
1) This would be ideal. +1
Also,
2) After reading the Bugzilla thread, is this issue something we'll have to contend with going forward regardless of how old or new the NIC is? i.e. Is this still an issue on 800 series Intel NICs?
One thing worth knowing whatever script you run: if a VF's own MAC ends up registered on the uplink, ixgbe silences that guest while i40e duplicates every frame to both. Neither driver warns, and withdrawing the entry heals it.
ctr's bridge fdb add is still the whole mechanism, and the scripts here build on it well.
The hookscript did not quite do it for me: it takes the MACs from the guest config, so the ones the bridge learns stay outside what it can see.
So mine ended up a small daemon:
https://github.com/Jimbambuli/sriov-mac-sync
It reacts to netlink events rather than polling, so an address reaches the filter as the bridge learns it.
It follows bonds and bridges stacked above the NIC, keeps VF addresses out, and withdraws only what it registered itself.
One static binary, no dependencies, .deb package.
I hope the little project is of use to somebody else here.
ctr's bridge fdb add is still the whole mechanism, and the scripts here build on it well.
The hookscript did not quite do it for me: it takes the MACs from the guest config, so the ones the bridge learns stay outside what it can see.
So mine ended up a small daemon:
https://github.com/Jimbambuli/sriov-mac-sync
It reacts to netlink events rather than polling, so an address reaches the filter as the bridge learns it.
It follows bonds and bridges stacked above the NIC, keeps VF addresses out, and withdraws only what it registered itself.
One static binary, no dependencies, .deb package.
I hope the little project is of use to somebody else here.
Very cool, and thank you for sharing.
Only after looking a bit more closely I noticed you used a lot of AI to create this.
That's okay, but then also add a disclaimer somewhere that you got a lot of help from AI. That way people know what to expect from the project.
Fair point, and you are right that it is a lot. I have added a note to the README: most of the code and docs were written by Claude working from my direction, on my hardware. What is not generated is the measurements. Every hardware claim comes from the cards named, and the harness that produced them is in the repo, so anyone can rerun it.