Description of problem: The latest update to virt-manager, release 0.8.7-2.fc14, introduced some problem I didn't have before. For some reason my message logs are filled up with messages like this: libvirtd: 13:13:38.083: error : interfaceGetXMLDesc:355 : internal error could not get interface XML description (netcf: NETLINK socket operation failed - couldn't find ifindex for interface `br0:1`) As soon as virt-manager runs, this message fills up the message log pretty fast, one message per second. It does not matter if a virtual machine is running at the time. Yes, I have an interface br0:1, but it's not used by any of the virtual machines and it's not mentioned in any configuration so I have no idea why virt-manager is suddenly keen to get hold of the interface. None of the older virt-manager versions I used so far has shown any interest in this interface, nor did any of them log such a message. I even tried to add this interface to the libvirt configuration, but the GUI doesn't accept an interface with a colon in its name. So, what I did for now is to downgrade virt-mananger to version 0.8.5-1.fc14. This fixes the problem for me. However, I would be more confident if I 1) knew why this message is generated now and 2) how to avoid it. Version-Release number of selected component (if applicable): 0.8.7-2 How reproducible: Create an alias interface with seom othe IPv4 address and start virt-manager. Steps to Reproduce: 1. ifconfig br0:1 192.168.7.7 netmask 255.255.255.0 up 2. virt-manager 3. Observe log output Actual results: libvirtd: 13:13:38.083: error : interfaceGetXMLDesc:355 : internal error could not get interface XML description (netcf: NETLINK socket operation failed - couldn't find ifindex for interface `br0:1`) Expected results: Silence Additional info:
This is ultimately an issue at the netcf layer. It is reporting existence of an interface 'br0:1' but is incapable of providing its config. There are two real issues here - It should be more robust and always be able to provide some kind of minimal config for any interface it reports as existing - Alias interfaces should not actually be reported at all. These are just a figment of imagination of the legacy net-tools commands, and do not exist for the kernel or iproute tools. They should just appear as additional IPv4 addresses within the main NIC config.
Agreed, trying to work around this in virt-manager would just be a pain. Reassigning to netcf Laine, any thoughts?
*** Bug 693013 has been marked as a duplicate of this bug. ***
So the problem is that netcf has a single list of interfaces, and assumes that all of those interfaces will have both config file info, as well as in-kernel info - it is totally reasonable to ask for the "inactive" xml of "br0:1". I'll need to think about this a bit, but I'm sure we can come up with some solution that makes sense. What has changed in virt-manager that has made this a problem? Is it now displaying the live status of the interfaces rather than just the static config info?
The problem exists on RHEL 6.1 (libvirt-0.8.7-18.el6.x86_64, netcf-libs-0.1.7-1.el6.x86_64), as well. And like in the closed bug 693013, it doesn't have to be related to aliased bridge interfaces: As long as there is at least one bridge interface (like "br1") which libvirt doesn't know about, there will be a storm of syslog messages when virt-manager is running. Should a separate BZ be opened for the RHEL 6.1 case, or is this BZ sufficient?
(In reply to comment #5) > The problem exists on RHEL 6.1 (libvirt-0.8.7-18.el6.x86_64, > netcf-libs-0.1.7-1.el6.x86_64), as well. And like in the closed bug 693013, it > doesn't have to be related to aliased bridge interfaces: As long as there is at > least one bridge interface (like "br1") which libvirt doesn't know about, there > will be a storm of syslog messages when virt-manager is running. > > Should a separate BZ be opened for the RHEL 6.1 case, or is this BZ sufficient? Thanks for reporting that; I cloned it to 6.1.
It happens not only with aliased interfaces, but with normal inactive too. I have ifcfg-br0, ifcfg-eth0: DEVICE=eth0 BOOTPROTO=none ONBOOT=yes BRIDGE=br0 and ifcfg-eth2: DEVICE=eth2 BOOTPROTO=dhcp HWADDR=00:0E:... ONBOOT=no Logs are filled with: libvirtd: 17:43:58.594: error : interfaceGetXMLDesc:355 : internal error could not get interface XML description (netcf: NETLINK socket operation failed - couldn't find ifindex for interface `eth2`)
A fix for this problem has been posted to netcf-devel: https://fedorahosted.org/pipermail/netcf-devel/2011-June/000579.html
netcf-0.1.9-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/netcf-0.1.9-1.fc14
Package netcf-0.1.9-1.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing netcf-0.1.9-1.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/netcf-0.1.9-1.fc14 then log in and leave karma (feedback).
Before I install the new netcf package for testing, I have a question. I don't have the netcf package installed: $ rpm -q netcf package netcf is not installed $ rpm -q virt-manager virt-manager-0.8.5-1.fc14.noarch If I try to update virt-manager to the "broken" version 0.8.7-2, netcf is *not* added as dependency: # yum update virt-manager [...] Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: virt-manager noarch 0.8.7-2.fc14 updates 962 k Transaction Summary ================================================================================ Upgrade 1 Package(s) Total download size: 962 k Is this ok [y/N]: So, here's my question. How can a packet which isn't installed, and which is no dependency of virt-manager can be the reason for the problem showing up in virt-manager? A short explanation would be helpful. I'd like to understand why installing a not yet installed package is supposed to fix the issue. Thanks, Corinna
Oh boy, never mind my last comment: [ENOCOFFEE] After sending it, it occured to me that the depndency is not on netcf but on netcf-libs. So I updated netcf-libs to 0.1.9-1 and virt-manager to 0.8.7-2. After restarting the libvirtd service, the problem went away. So, afaics, this fixes it. Thanks, Corinna
netcf-0.1.9-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.