Edward and I have had a multi-day private conversation in IRC on the topic of this mail. I was planning to update this thread with an email, but forgot until now :-/ On 9/24/20 10:54 AM, Daniel P. Berrangé wrote: Right. The bus number that is visible in the guest is 100% controlled by the device firmware (and possibly the guest OS?), and there is no way for qemu to explicitly set it, and thus no way for libvirt to guarantee that the bus number in libvirt XML will be what is seen in the guest OS; the bus number in the XML only has meaning within the XML - you can find which controller a device is connected to by looking for the PCI controller that has the same "index" as the device's "bus". Actually we looked at this offline, and the "messing up" that's occurring is not due to any change in PCI address from one boot to the next. The entire problem is caused by  the guest OS using traditional "eth0" and "eth1" netdev names, and making the incorrect assumption that those names are stable from one boot to the next. In fact, it is a long-known problem that, due to a race between kernel code initializing devices and user processes giving them names, the ordering of ethN device names can change from one boot to the next *even with completely identical hardware and no configuration changes. Here is a good description of that problem, and of systemd's solution to it ("predictable network device names"): https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInter... Edward's inquiry was initiated by this bugzilla:   https://bugzilla.redhat.com/show_bug.cgi?id=1874096 You can see in the "first boot" and "second boot" ifconfig output that the same ethernet device has the "altname" enp2s1, and the same device has the altname enp3s0 during both runs; these names are given by systemd's "predictable network device name" algorithm (which bases the netdev name on the PCI address of the device). But the race between kernel and userspace causes the "ethN" names to be assigned differently during one boot and the next. In order to have predictable netdev names, the OS image needs to stop setting net.ifnames=0 on the kernel command line. If they like, they can give their own more descriptive names to the devices (methods arae described in the above systemd document), but they need to stop relying on ethN device names. (note that this experience did uncover another bug in libvirt, which *might* contribute to the racy code flip flopping from boot to boot, but still isn't the root cause of the problem - in this case libvirtd is running privileged, but inside a container, and the container doesn't have full access to the devices' PCI config data in sysfs (you can see this when you run "lspci -v" inside the container, you'll notice "Capabilities: <access denied>". One result of this is that libvirt mistakenly determines the VF is a conventional PCI device (not PCIe), so it auto-adds a pcie-to-pci-bridge, and plugs the VF into that controller. I'm guessing that makes device initialization take slightly longer or something, changing the results of the race. I'm looking into changing the test for PCIe vs. conventional PCI, but again that isn't the real problem here) The entire point of <interface type='hostdev'> is to be able to set the MAC address (and optionally the vlan tag) of a VF when assigning it to a guest, and the only way to set those is via the PF. If you use plain <hostdev>, then libvirt has no idea that the device is a VF, so it doesn't look for or try to access its PF. So, you're doing the right thing - since your container has no access to the PF, you need to set the MAC address / vlan tag outside the container (via the PF), and then use <hostdev> (which doesn't do anything related to PF devices).