Detect SR-IOV VFs via AZURE_UNMANAGED_SRIOV udev property#444
Conversation
Replace the sriov-vf ifalias check in the MAC address detector with
detection of the `AZURE_UNMANAGED_SRIOV=1` udev property applied by
azure-vm-utils to SR-IOV VF devices bonded under hv_netvsc.
This makes MAC-based interface detection correct on stemcells that
ship azure-vm-utils (e.g. Ubuntu Noble) without requiring a parallel
stemcell-side ifalias workaround.
Stemcells that currently set ATTR{ifalias}="sriov-vf" (e.g. Ubuntu
Jammy) already set ENV{AZURE_UNMANAGED_SRIOV}="1" alongside, so the
new check is a strict superset of the previous behaviour.
The property is read from /run/udev/data/n<ifindex>, where udev
persists per-device properties as lines of the form "E:KEY=VALUE".
|
Warning Review limit reached
More reviews will be available in 29 minutes and 49 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughLinux MAC address detection now checks per-interface udev records for 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@platform/net/mac_address_detector_test.go`:
- Around line 143-151: The test in mac_address_detector_test.go does not reach
the missing-udev-data branch because stubInterfacesWithVirtual only creates
address/ifalias and never an ifindex, causing isAzureUnmanagedSRIOV to fail
earlier. Update the test setup so the interface has a valid ifindex file while
intentionally omitting the /run/udev/data/n<ifindex> file, then keep the
DetectMacAddresses assertion in the same test to verify the missing-udev-data
path is exercised. Use the existing helpers and the isAzureUnmanagedSRIOV flow
to ensure the branch under test is actually hit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f6a411a7-cb17-4226-a7b0-06a1c22cc1cf
📒 Files selected for processing (2)
platform/net/mac_address_detector.goplatform/net/mac_address_detector_test.go
Replace the sriov-vf ifalias check in the MAC address detector with detection of the
AZURE_UNMANAGED_SRIOV=1udev property applied by azure-vm-utils to SR-IOV VF devices bonded under hv_netvsc.This makes MAC-based interface detection correct on stemcells that ship azure-vm-utils (e.g. Ubuntu Noble) without requiring a parallel stemcell-side
ifaliasworkaround.Stemcells that currently set
ATTR{ifalias}="sriov-vf"(e.g. Ubuntu Jammy) already setENV{AZURE_UNMANAGED_SRIOV}="1"alongside, so the new check is a strict superset of the previous behaviour.The property is read from
/run/udev/data/n<ifindex>, where udev persists per-device properties as lines of the form"E:KEY=VALUE".Self-Validation
Built the agent, baked it into the latest noble stemcell and re-deployed with accelerated-networking enabled on Azure. Based on the logs it looks like the agent is going the right code path and ignores the VF interface (which uses
mlx5_coredriver):