$ sudo python -c 'import libvirt; conn = libvirt.open("qemu:///system"); print conn.listAllInterfaces(); print conn.listInterfaces();' [] ['lo'] $ rpm -q libvirt-daemon libvirt-daemon-1.0.5.2-1.fc19.x86_64 I can reproduce on two f19 machines at least.
This is almost surely due to differences in what anaconda and/or NM are putting in the ifcfg files. netcf assumes/requires that the ifcfg file have a "DEVICE" setting, and that the value of $DEVICE match the suffix of the ifcfg filename. This of course isn't always true, but for awhile now people have been noticing that DEVICE isn't always set. Now I see that it's gone beyond that - I have one F19 system that was installed from scratch. It has an ethernet interface that is called 'p8p1' in the output of ifconfig. However, its ifcfg file is called "ifcfg-enp7s5", and makes no mention of "p8p1" at all, much less setting the DEVICE name. Making netcf work with the way that NM and anaconda have started using the ifcfg files is going to "take some time" to say the least. Note that if you change the name of the ifcgfg file to match the device's name, and add "DEVICE=whatever" (where "whatever" is the device's name) to that file, then it should be properly listed, and will also be properly recognized by NM.
Yeah that likely explains why nothing but 'lo' shows up in my output. But the bug report was more about listAllInterfaces returning an empty list, but old style listInterfaces() returns ['lo']. listAllInterfaces specifically must be buggy
Actually this is fixed upstream/rawhide it was the commit that triggered the CVE. Not really a big deal to backport though so just closing as RAWHIDE