[william-gr]

Why

The appliance has one NIC, the one the suite reaches its API on, so the E2E
suite cannot apply an interface change. interface.commit re-applies every
interface, and a VLAN, bridge or LAGG built on the only NIC could take away the
suite's only path to the appliance. truenas/webui#14537 (commit a VLAN, a bridge
and a LAGG with Test Changes and Save Changes, then delete them) is on hold for
that reason.

Change

• New input spare-nics, 0 to 9, default 0. Nothing changes for existing
  callers, nor for github-truenas-runner's image build, which fetches these
  scripts.
• Each spare NIC is a virtio NIC alone on a qemu hub of its own
  (-netdev hubport,hubid=N + -device virtio-net-pci). Its link is up, and
  there is no DHCP, no route and no peer. That is why this is not a second
  -nic user,restrict=on: user-mode networking always runs a DHCP server, and
  middleware starts DHCP on every physical NIC while its interfaces table is
  empty. TrueNAS's dhcpcd has noipv4ll, so the NIC should not get a 169.254
  address either.
• After the management NIC on the command line, so it keeps its PCI slot
  and its interface name whatever the count.
• Fixed MACs, 52:54:00:e2:e0:01 and up, exported space-separated as
  TN_SPARE_NICS. The suite matches interface.query's state.link_address
  instead of guessing which NIC has no address.
• ha: true with spare-nics set fails with an error, as extra-disk-gb
  does, instead of ha.sh silently ignoring it.
• The boot line names them (…, 10 data disks of 10G, 1 spare NIC), and the
  README's input table and appliance.sh's header list the setting.

qemu warns hub N is not connected to host network once per spare NIC at boot.
That is expected, and the comment beside the arguments says so.

Testing

• shellcheck -x appliance.sh ha.sh lib.sh and actionlint are clean, and
  node scripts/check-input-refs.js reports that all input references resolve.
• qemu 7.2 (Debian bookworm), with the management -nic user and two spare NICs
  built as start builds them. info network shows each spare on its own hub
  with its fixed MAC, and the user-mode NIC unchanged. info pci puts the
  management NIC at device 2 and the spares at 3 and 4.
• I have not booted a TrueNAS appliance with it. The first E2E run that passes
  spare-nics: 1 is that test. Its boot line should read …, 1 spare NIC, and
  interface.query should show a NIC with MAC 52:54:00:e2:e0:01 and no IPv4
  address.

[github-actions]

LOW: The MACs only show up in TN_SPARE_NICS when export-env is 'true'. start prints the line, but the only thing that passes it on is grep '^TN_' >> "$GITHUB_ENV", and there's no action output for it the way ssh has one. A caller with export-env: 'false' and spare-nics: 1 gets the NIC but no way to read its MAC. This is the same as TN_DOMAIN and the other TN_* values that have no output, so it isn't a defect. The description could say it depends on export-env, or the action could add a spare-nics output.

[github-actions]

One finding: one LOW. No human review needed.

LOW: TN_SPARE_NICS only reaches the caller through $GITHUB_ENV, so a caller with export-env: 'false' cannot read the spare NICs' MACs. Details are inline on action.yml:77.

What I checked:

• Existing callers: with the default '0', seq 1 0 gives nothing, so nics is empty, nothing is added to the boot line, and TN_SPARE_NICS is not printed. The qemu command line is the same as before.
• Input check: ^[0-9]$ rejects anything outside 0–9 before qemu starts. TN_SPARE_NICS goes to the job environment through the existing grep '^TN_'.
• HA: ha: true with spare NICs fails in action.yml before ha.sh runs, the same way as extra-disk-gb.
• Hubs and PCI slots: hub IDs 1–9 don't clash with the management -nic user, which uses no hub. The management NIC stays ahead of the spares, so its PCI slot doesn't change.
• Snapshots: the savevm/loadvm baseline is taken after boot with the same devices, so the extra NICs don't break revert.
• README: the input table is updated.

CI: check-ticket fails because the PR title names no ticket (the previous PR's title began with NAS-144815 / …). That is the title, not the code. The appliance-script, input-ref and lint checks pass.

[github-actions]

Approved. 1 finding(s): 1 LOW.

Nothing blocks and no human review is needed.

[bugclerk]

Jira URL: https://ixsystems.atlassian.net/browse/NAS-144884

[bugclerk]

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.