Problem with virInterfaceCreate(), IFF_UP, and NetworkManager

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Due to "a checkered past" (a myriad of minor issues, changing over
time), libvirt's semi-official position on the virInterface*() APIs and
NetworkManager is that virInterface*() is only supported if NM is
disabled. We do still attempt to make it work as well as possible, but
normally I only test those APIs on systems that have NM disabled and use
the network service (RHEL/Fedora/CentOS systems here) instead.

On a seemingly unrelated note, a few months ago mprivozn pushed a patch
that makes it an error to call virInterfaceCreate() (i.e. "ifup") for an
interface that is already active. (the "active" state of an interface is
determined by looking at an interface's IFF_UP flag (and also
IFF_RUNNING, if the interface isn't a bridge device). Previously, this
was allowed, as it is common practive to ifup an interface to make new
config take effect.

Last week, I happened to test the "virsh iface-bridge" command on a
system with NM enabled. That command gave an error about the interface
being already active, so I tried again, this time ifdowning the
interface in advance - I *still* got the error. Further investigation
and questioning of NM developers led me to the realization that when NM
is enabled, all interfaces *always* have IFF_UP and IFF_RUNNING set,
even if they are ifdowned. Further, if NM is active there is no way to
determine an interface's "active" status via iotctl() or netlink;
instead, must query to determine if NM is active, and if it is you must
call a NM API instead (I got this much information from NM developers
directly; haven't investigated yet exactly what the API is).

NM developers say that this pinning-up of the IFF_UP flag has been done
for a long time, and is necessary to do interface auto-config. I think
it is violating a long-standing assumption (if not a standard) about the
meaning of IFF_UP, and I'm not convinced that it really is a necessity
(certainly once a config file is present for an interface, it shouldn't
be needed), but then I haven't spent as much time in that problem space
as they have.

In the meantime, the virInterfaceCreate() API fails 100% of the time on
any system that has NM enabled. My dilemma now is whether to attempt to
affect change in NM's use of IFF_UP so that it once again can be used as
an indicator of whether or not an interface is active, or to just give
in and 1) officially declare that virInterface*() isn't supported if NM
is enabled until 2) we add code to netcf that detects when NM is active
and learns how to query interface status from NM instead of the standard
ioctl(SIOCGIFFLAGS).

And if the latter is preferred, should we in the meantime perhaps revert
the patch that made virInterfaceCreate() an error if the interface was
active? Or just leave it completely broken?

Any opinions?

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]