On 10/10/26 5:05 AM, sst11336677@gmail.com wrote:

Hi,

I am using <interface type='hostdev'> to assign SR-IOV VFs to QEMU/KVM guests. libvirt lets me set the MAC address and the VLAN tag on that element, but there is no way to set an IP address.

I would like to know which of these is the case:

(a) libvirt cannot set it. The guest's IP address lives in the guest's own network stack, and with VFIO the host is not in the data path, so there is nothing host-side that could apply it.

This ^^^. Both the MAC address and the VLAN tag of the SRIOV VF are things that can be set directly on the hardware, which libvirt does prior to starting the guest QEMU process or attaching the device to an already-running QEMU process. The IP address can only definitively set by the guest OS itself, which neither libvirt nor QEMU has any visibility to (regardless of whether the device in question is real hardware assigned with VFIO or a virtual device created by QEMU). In cases where the guest is using DHCP to acquire an IP address and libvirt has a path to controlling the config of the DHCP server, it can be possible to use <ip> configuration from libvirt to set the IP address for the given MAC address in the DHCP server, and thus in the guest (as long as the guest is actually paying attention to DHCP - the final decision still remains with the guest, which is *not* the case with the MAC address (visible to the guest, but not always changeable by the guest (never changeable in the case of VFIO-assigned VFs)) or the VLAN tag (not even visible to the guest - it thinks it's traffic isn't tagged at all). For the QEMU driver, libvirt only supports this "setting guest IP from domain config via DHCP" for <interface type='user'> and <interface type='vhostuser'> (in the latter case only if the backend process on the host is passt). You can *indirectly* suggest the guest IP for <interface type='network'> if the network is a libvirt virtual network - you just add a static host entry for that particular MAC address to the libvirt virtual network config. In the case of VFIO-assigned SRIOV VFs, none of these are applicable, because the DHCP server (if any) for the network is completely outside the scope/control of libvirt, and probably on a totally different machine.

(b) libvirt could set it, but it has simply never been implemented.

I believe the answer is (a), because the <ip> element was added to <hostdev mode='capabilities' type='net'> only for the LXC case, where the host owns the container's network namespace:

Originally, the <ip> element even for interfaces was only supported in the case of LXC <interface type='ethernet'> likely because not doing that would leave the veth device created by libvirt with some random IP (or no IP); I've never used <hostdev mode='capabilities type='net'> but that seems like the same issue. At any rate, L3 network config has been generally considered out of scope for QEMU.

https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/6OHH...

But I would like that confirmed rather than inferred.

If it is (a), would you consider saying so in the documentation? The hostdev interface section of formatdomain does not mention IP addresses at all,

so there is nothing telling a reader that this is out of scope by design, or pointing them at the alternatives (a DHCP reservation keyed to the MAC that libvirt already sets, cloud-init, or the guest agent). Yeah, generally the documentation that we include with libvirt details what you *can* do rather than what you *can't* do :-) and in an attempt to be hypervisor-agnostic, it can sometimes seem vague. I just read

Also originally <hostdev> was only considered to be a method of attaching a generic PCI device to a guest, and anything beyond the PCI address was assumed out of scope. Even when we added support for setting the MAC/VLAN of a PCI device that just happened to be an SRIOV VF, we did that using <interface type='hostdev'> rather than plain <hostdev> through the bits about configuring IP address in formatdomain.rst, and it seems like it could have a bit added to explicitly say "setting the guest IP address with <ip> is only possible in X, Y, and Z circumstances, and has these caveats ...". I just sent a patch to the list suggesting some additions, but am unsure if it's maybe too verbose for that file: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4TQ2...