Description of problem: If the user specifies a sriov network device like the below, with a pciAddress, it passes validation but the specified pciAddress does not end up in the libvirt xml. - macAddress: aa:bb:cc:dd:ee:ff name: nic-1 pciAddress: "0000:XY:00.0" sriov: {} When defining the interface, the converter jumps SR-IOV ones here [1], so it does not get to the part where the guest side address of the VF is set, a few lines below, here [2]. This makes it hard for the user to use Scheme 3 of network interface predictable/persistent naming [3] with SR-IOV devices. Note the above works fine for para-virt devices like virtio-net. [1] https://github.com/kubevirt/kubevirt/blob/main/pkg/virt-launcher/virtwrap/converter/network.go#L53 [2] https://github.com/kubevirt/kubevirt/blob/main/pkg/virt-launcher/virtwrap/converter/network.go#L78 [3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/consistent-network-interface-device-naming_configuring-and-managing-networking How reproducible: - Still looking for HW to confirm on latest, happens with customer on 4.8.5.
Thanks for reporting this. The team will be looking into this issue in the next sprint.
Created attachment 1868764 [details] VMI object with two SR-IOV NICs with custom PCI and MAC addresses
Created attachment 1868766 [details] virt-launcher Pod object
Created attachment 1868767 [details] virt-launcher log file
Created attachment 1868768 [details] domain.xml
Created attachment 1868769 [details] ip link command output from the guest OS
Created attachment 1868770 [details] lshw command output from the guest OS
Created attachment 1868771 [details] ip link command output from the node
Created attachment 1868772 [details] VF to PCI mapping from the node
Created attachment 1868773 [details] SR-IOV CNI output 1
Created attachment 1868774 [details] SR-IOV CNI output 2
Created attachment 1868777 [details] NetworkAttachmentDefinition 1
Created attachment 1868779 [details] NetworkAttachmentDefinition 2
There is a bug that masked this bug https://bugzilla.redhat.com/show_bug.cgi?id=2070050 A more accurate description of this bug is: Cannot reliably set multiple SR-IOV NICs with different properties (pciAddress, bootOrder, macAddress or setting from the NetworkAttachmentDefinitions). The attachments are a recreation of this bug on the latest upstream code.
(In reply to Orel Misan from comment #26) > There is a bug that masked this bug > https://bugzilla.redhat.com/show_bug.cgi?id=2070050 But only on 4.9 and 4.10 right, 4.8 can start without duplicate pci addresses, its just all scrambled. > A more accurate description of this bug is: Cannot reliably set multiple > SR-IOV NICs with different properties (pciAddress, bootOrder, macAddress or > setting from the NetworkAttachmentDefinitions). > The attachments are a recreation of this bug on the latest upstream code. Are you saying the MAC address with randomly float around the multiple NICs too, not just PCI Address and bootOrder? Seems to be working for the customer, but could be luck (like Petr mentioned). I'm uploading the data soon.
Thank you for the information. > Are you saying the MAC address with randomly float around the multiple NICs too, not just PCI Address and bootOrder? > Seems to be working for the customer, but could be luck (like Petr mentioned). At the moment there is an issue to distinguish between multiple SR-IOV NICs that have different properties from one another. for example if you specify a list of multiple SR-IOV NICs, each with a custom PCI address and a MAC address, it is not guaranteed to be reflected correctly in the domain, and thus in the guest OS.
(In reply to Germano Veit Michel from comment #27) > But only on 4.9 and 4.10 right, 4.8 can start without duplicate pci addresses, its just all scrambled. This bug https://bugzilla.redhat.com/show_bug.cgi?id=2070050 is only affecting versions 4.9 4.10.
(In reply to Orel Misan from comment #29) > At the moment there is an issue to distinguish between multiple SR-IOV NICs > that have different properties from one another. > for example if you specify a list of multiple SR-IOV NICs, each with a > custom PCI address and a MAC address, it is not guaranteed to be reflected > correctly in the domain, and thus in the guest OS. Yes, this is exactly what this BZ is about, more specific to the pci address. Thanks for clarifying everything!
No problem. Can you please update this bug's description with the new information? I suggest to also remove the references to the code because they are misleading.
Unfortunately this cannot be done, BZ does not allow to edit comments. My BZ comment #0 was quite bad start, and then there is a lot of back and forth and noise because of that, plus the extra bug on 4.9 and 4.10. Let's close this one as other people may get lost too, I'll open a new one with a proper problem description and we continue from there. Will also have to KCS the child BZ from this (4.9/4.10 closure). *** This bug has been marked as a duplicate of bug 2070772 ***