test: add e2e validation for MANA accelerated networking#8832
test: add e2e validation for MANA accelerated networking#8832titilambert wants to merge 15 commits into
Conversation
|
This change is part of the following stack: Change managed by git-spice. |
|
@microsoft-github-policy-service agree company="Microsoft" |
There was a problem hiding this comment.
Pull request overview
Adds end-to-end validation for MANA (Microsoft Azure Network Adapter) accelerated networking on newer VM series, expanding the e2e suite to assert both device/driver presence and datapath correctness on Ubuntu 22.04/24.04 and Azure Linux V3.
Changes:
- Added VMSS helper to explicitly enable Accelerated Networking on the primary NIC for targeted MANA scenarios.
- Introduced MANA validation helpers (PCI device, driver availability, VF bonding, VF traffic counters) and conditionally ran them from
ValidateCommonLinuxwhen MANA hardware is detected. - Added dedicated e2e scenarios for Ubuntu 22.04, Ubuntu 24.04, and Azure Linux V3 on a V6 SKU, plus a new
Tags.MANAfilter flag.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| e2e/vmss.go | Adds a helper to enable Accelerated Networking on the VMSS primary NIC. |
| e2e/validators.go | Implements MANA detection and validation steps (PCI/driver/VF bonding/traffic). |
| e2e/validation.go | Conditionally runs MANA validation as part of common Linux validations when hardware is detected. |
| e2e/types.go | Adds a MANA tag to scenario filtering. |
| e2e/scenario_test.go | Adds three VM-series coverage scenarios validating MANA on V6 SKUs across OSes. |
titilambert
force-pushed
the
add-e2e-tests-for-mana
branch
from
81bb13d to
294a4f3
Compare
titilambert
force-pushed
the
add-e2e-tests-for-mana
branch
from
e685e10 to
1e8d5e4
Compare
titilambert
force-pushed
the
add-e2e-tests-for-mana
branch
from
acc7ca8 to
cc1fdc0
Compare
titilambert
requested review from
SriHarsha001,
runzhen and
xuexu6666
as code owners
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Signed-off-by: Thibault Cohen <thicohen@microsoft.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
titilambert
force-pushed
the
add-e2e-tests-for-mana
branch
from
8a906bc to
68fcd3a
Compare
|
Should v8 be included in these E2Es? I see the title of the user story says v7/v8. You might need to check if there are available v8 VMs before adding those tests though. We may have low capacity which will lead to failures |
|
You could add a FIPS + MANA scenario based on Test_Ubuntu2204Gen2FIPSTL. FIPS kernels have historically had different driver-loading behavior so we might want to test functionality |
|
Add v6/v7 only support NVMe disk controllers |
| if primaryNIC.Properties == nil { | ||
| primaryNIC.Properties = &armcompute.VirtualMachineScaleSetNetworkConfigurationProperties{} | ||
| } | ||
| primaryNIC.Properties.EnableAcceleratedNetworking = to.Ptr(true) |
| // The "; true" ensures exit 0 regardless of curl's result — the gateway has | ||
| // no HTTP server so connections will fail, but TCP SYN packets still traverse | ||
| // the VF (incrementing vf_tx_packets). The real assertion is the counter delta below. | ||
| curlCmd := fmt.Sprintf("for i in $(seq 1 %d); do curl -s -o /dev/null -m 1 http://%s/ 2>/dev/null; done; true", requestCount, gatewayIP) | ||
| execOnVMForScenarioOnUnprivilegedPod(ctx, s, curlCmd) |
|
for the SKU selection, there was a logic that @lilypan26 added to target the next Gen VM sku. might be good to sycn with her to understand when and how the specific v7/v8 hardware tests are exectued |
| }) | ||
| } | ||
|
|
||
| func Test_Ubuntu2404_MANA_V7(t *testing.T) { |
There was a problem hiding this comment.
I don't think we have dedicated tests for hardware, we have a suite that runs on the V7 or V8 hardware. we shouldnt be duplicating the tests by hardware I think.
| // enableAcceleratedNetworking explicitly enables Accelerated Networking on the | ||
| // primary NIC of the VMSS. This ensures MANA (Microsoft Azure Network Adapter) | ||
| // is active on the VM, which is required for V5+ VM series. | ||
| func enableAcceleratedNetworking(vmss *armcompute.VirtualMachineScaleSet) { |
There was a problem hiding this comment.
not all sku support AcceleratedNetworking, will this fail on SKU where AN isn't supported ? or will it silently accept ?
what is the consequences if AN isn't working on a VM where Mana driver is present ? Are we able to detect that ?
What this PR does / why we need it:
Adds end-to-end tests validating that MANA (Microsoft Azure Network Adapter)
accelerated networking is properly configured on V6 VM series. The tests cover
Ubuntu 22.04, Ubuntu 24.04, and Azure Linux V3.
Validations added:
Additionally, MANA validation is run conditionally in
ValidateCommonLinuxon any VM where MANA hardware is detected (V5+ series).
Which issue(s) this PR fixes:
Fixes #