Safely rebind SR-IOV virtual functions with Netplan

You will identify an SR-IOV physical function (PF), confirm the installed Netplan command, and rebind that PF's virtual functions (VFs) to their driver with an explicit interface name. Allow 10 to 15 minutes for a prepared maintenance window. The rebind can interrupt traffic or detach a VF from a workload, so this is an operational change, not a harmless status query.

This guide follows the installed netplan-rebind(8) manual and Netplan 1.1.2 from the netplan.io package on Ubuntu 24.04. The package version on the reference host is 1.1.2-8ubuntu1~24.04.3. Other releases can differ, so check the local help before copying an option into a script.

1. Confirm the command and the maintenance boundary

Run the read-only checks as your normal account. They confirm that Netplan is installed and show the syntax without touching network devices:

$ dpkg-query -W -f='${Package} ${Version}\n' netplan.io
netplan.io 1.1.2-8ubuntu1~24.04.3
$ command -v netplan
/usr/sbin/netplan
$ netplan rebind --help
usage: /usr/sbin/netplan rebind [-h] [--debug] [--root-dir ROOT_DIR]
                                [netdevs ...]

The installed command also advertises --root-dir, while the installed manual documents -h, --help, --debug, and a space-separated list of interface names. This guide uses only the documented interface list and --debug. Do not assume that a flag from a newer binary is available on another host.

2. Identify the physical function

netplan rebind takes physical-function interface names, not VF names. Use the host's own interface inventory rather than guessing a name:

$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp5s0f0         UP             52:54:00:12:34:56
enp5s0f1         DOWN           52:54:00:12:34:57

The output is host-specific. An interface name such as enp5s0f0 is only an example. Confirm the candidate against your platform's SR-IOV inventory and the workload using it. If you need to distinguish a PF from a VF, inspect the device information without changing it:

$ ethtool -i enp5s0f0
driver: example-driver
version: host-specific

Not every driver exposes identical fields, and the exact output is not a Netplan contract. The useful result is a consistent interface name and a known maintenance target. If the interface is a bond member, bridge port, or assigned to a guest, record that dependency before continuing.

3. Check the Netplan configuration before rebinding

Netplan's SR-IOV model associates a VF with a PF through the link property. A minimal configuration fragment looks like this:

network:
  version: 2
  ethernets:
    enp5s0f0:
      mtu: 1500
    vf0:
      link: enp5s0f0

This is an example of the relationship, not a complete configuration to paste over an existing file. Preserve the host's current addressing, routes, VLANs, renderer and other settings. A VF definition can use a Netplan ID that is different from the kernel interface name, so check the real files under /etc/netplan/ and the generated state before acting:

$ sudo netplan get all
network:
  ethernets:
    enp5s0f0:
      mtu: 1500
    vf0:
      link: enp5s0f0

netplan get all is a read-only inspection. If it fails, resolve the configuration error first. Do not run netplan apply as a substitute: apply is a separate operation with a wider effect and is outside this guide.

4. Rebind one physical function

Warn anyone using the affected network path, stop or evacuate dependent workloads according to your platform procedure, and then run the command with the PF name. The rebind operation normally requires elevated privileges because it changes kernel device-driver attachment:

$ sudo netplan rebind enp5s0f0

Do not add a VF name to this command. The manual describes the positional argument as a space-separated list of physical-function interface names. For several independent PFs, list each deliberately:

$ sudo netplan rebind enp5s0f0 enp5s0f1

Keep the list short while troubleshooting. An explicit one-PF run makes it easier to identify the interface responsible for a failure and limits the possible blast radius. If you need diagnostics, add the documented debug switch:

$ sudo netplan --debug rebind enp5s0f0

Debug output is for diagnosis; it does not make the operation safer or perform a dry run. There is no dry-run form documented by netplan-rebind(8). Treat a successful exit as completion of the rebind request, not proof that every VF workload has recovered.

5. Verify the result and recover if needed

After the command returns, inspect links and the device's driver state. These checks are read-only:

$ ip -br link
$ ethtool -i enp5s0f0
$ ip link show

Confirm that the expected PF and VFs are present, that the driver is the intended one, and that the dependent workload has regained its network path. Use the workload's own health check as well. The exact link state, VF names and driver output depend on the NIC, kernel, driver and deployment.

If a VF or workload does not return, stop repeating the rebind blindly. Check kernel messages and the service or virtualisation manager that owns the device:

$ sudo journalctl -k -b --no-pager | tail -n 100
$ sudo systemctl status your-dependent-service.service

Replace the service placeholder with a real unit name. If rebinding caused an outage, the practical recovery is to restore the previous device assignment or service configuration, then restart only the affected consumer according to its documented procedure. Keep the original Netplan files intact. Changing configuration and applying it is a separate, potentially disruptive change; do not improvise it during an incident without an approved recovery plan.