On 10/10/26 5:05 AM, [email protected] 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/[email protected]/message/6OHH6V7FLIDOEDXQ5TGY4RLDV4AFV3IS/
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,
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>
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
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/[email protected]/thread/Z4TQ2OPLOBQGW2JVKEGNLRBTCAGED2I4/
