$ sudo ncftool dumpxml --live p14p1 <?xml version="1.0"?> <interface name="p14p1" type="ethernet"> <mac address="90:2b:34:66:3a:7e"/> <protocol family="ipv4"> <ip address="192.168.1.149" prefix="24"/> </protocol> <protocol family="ipv6"> <ip address="fe80::922b:34ff:fe66:3a7e" prefix="64"/> </protocol> </interface> $ sudo ncftool list --all lo Affects libvirt as well, which screws up some virt-manager validation as mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=1065042
This is most likely due to the ifcfg file missing the DEVICE= line, which is required by netcf when it is creating its list of devices. The "name" of a network device can appear in at least three different places, and although they used to usually match, they don't have to match, and increasingly they do not match: 1) DEVICE attribute in ifcfg file 2) NAME attribute in ifcfg file 3) ifcfg filename (everything after "ifcfg-" netcf checks (1) and (3), and requires them to match. It ignores 2. Based on recent practices in NetworkManager, this doesn't always work well, since NetworkManager (and anaconda) tend to no longer populate DEVICE, and very often have a different value in NAME and yet another in the ifcfg filename (and *both* of them are different from the actual name of the device). Also entering into this mix is the UUID, which NM people say is the only *real* persistent key to any network device (if I'm recalling my NM lore correctly). In light of all this, I'm not really sure what course can/should be taken to arrive at something useful. Should netcf base the output of "ncftool list" on the list of interfaces returned from netlink rather than the contents of the config files? That seems of dubious merit, as the original intent of netcf was to simplify configuring network devices, and the list of devices returned by netlink includes many transient devices that have no persistent config. Or, on the other hand, should we look at NAME if DEVICE isn't present? that seems likely to fail as well, because NAME is often set to something different from the device name, and also different from the ifcfg file name. I would welcome any suggestions on how to resolve this mismatch of config paradigms in a reasonable and useful manner.
*** This bug has been marked as a duplicate of bug 911806 ***