+++ This bug was initially created as a clone of Bug #2070772 +++

Description of problem:

pciAddress of SR-IOV NICs defined in the VM is not respected, in the generated libvirt XML and therefore inside the Guest the NIC properties are randomly mixed.

For example, see these 4 SR-IOV NICs defined:

• macAddress: 02:9f:a6:00:01:40
  model: virtio
  name: nic-1
  pciAddress: "0000:20:00.0"
  sriov: {}
• macAddress: 02:9f:a6:00:01:41
  model: virtio
  name: nic-2
  pciAddress: "0000:21:00.0"
  sriov: {}
• macAddress: 02:9f:a6:00:01:42
  model: virtio
  name: nic-3
  pciAddress: "0000:22:00.0"
  sriov: {}
• macAddress: 02:9f:a6:00:01:43
  model: virtio
  name: nic-4
  pciAddress: "0000:23:00.0"
  sriov: {}

But inside the Guest 20:00.0 and 22:00.0 are swapped:

bus info: pci@0000:20:00.0
serial: 02:9f:a6:00:01:42

bus info: pci@0000:21:00.0
serial: 02:9f:a6:00:01:41

bus info: pci@0000:22:00.0
serial: 02:9f:a6:00:01:40

bus info: pci@0000:23:00.0
serial: 02:9f:a6:00:01:43

Version-Release number of selected component (if applicable):
4.8.4

How reproducible:
100%

Steps to Reproduce:
1. Create VM with many SR-IOV NIC with pciAddress and macAddress defined
2. Look inside the Guest, they are often mixed up.

— Additional comment from Germano Veit Michel on 2022-03-31 21:17:17 UTC —

— Additional comment from Germano Veit Michel on 2022-03-31 21:22:29 UTC —

This bug is blocked on 4.9 and 4.10 by BZ2070050, which makes the VM fail to start.
On 4.8 the VM starts, but the problem in comment #0 occurs.

— Additional comment from Germano Veit Michel on 2022-03-31 22:08:08 UTC —

Can the macAddress of the interface inside the Guest be used to correctly identify the matching SR-IOV resource (VF) connected to the specific network, or that is also cannot be trusted and may float around?

— Additional comment from Edward Haas on 2022-04-04 06:47:02 UTC —

(In reply to Germano Veit Michel from comment #3)
> Can the macAddress of the interface inside the Guest be used to correctly
> identify the matching SR-IOV resource (VF) connected to the specific
> network, or that is also cannot be trusted and may float around?

Short answer is yes, the mac address is the best identifier.

The current issue is that we are not able to correctly differentiate
between VF/s of the same resource inside the pod (virt-launcher).
The MAC address is set before the VF is passed to the pod, in the
pod we cannot "see" that mac (the device is bound to the VFIO driver),
but once detected in the guest (as a network driver), the mac is revealed
and you can trust it.

Unless explicitly requested, the MAC address is immutable and no one can
change it in the guest.

Hope this helps.

— Additional comment from Germano Veit Michel on 2022-04-04 23:50:58 UTC —

Thanks Eddy, nice to see you here

The customer is using that as a workaround and so far it seems OK.