[libvirt-users] Problem with bridged network configuration

[Bob]

Caveat: I apologize in advance for the ranting tone of this mail, but I 
have been burned too many times and wasted too much time on this 
feature. I can no longer discuss this feature with the degree of 
objectivity that would be desired.

The executive summary is that the libvirt documentation works, and I 
have no beef with it. My issue is with the "Predictable Network 
Interface Names" feature recently introduced to Linux.

But since you asked, comments inline below...

<rant>

On 11/13/2013 5:00 AM, Laine Stump wrote:
> On 11/12/2013 06:52 PM, Bob Doolittle wrote:
>> For the record - I figured this out so am sharing the result for
>> posterity:
>>
>> The issue was that I didn't follow the instructions literally. Since,
>> once booted, my primary NIC name was "em1" I assumed I had to create
>> an initscript called ifcfg-em1 rather than ifcfg-eth0 as described in
>> the doc.
> But you assumed correctly.

You would think so, wouldn't you? But you've underestimated the baroque 
complexity of the feature. The title "Predictable Network Interface 
Names" must have been ironic, because the behavior of that feature could 
only be considered "predictable" in the sense that all Von Neumann 
machines are deterministic and therefore their results are always 
predictable if you take into account their inputs. The best that can be 
said for this feature is that the result is "persistent" across network 
hardware changes, but surely not "predictable" except by somebody who 
has worked with the code extensively and understands obscure hardware 
details about their particular machine (e.g. backplane topology and BIOS 
hardware enumeration algorithms).

It turns out (and I challenge anyone to find documentation for this) 
that if you follow the instructions literally the right thing happens, 
because it appears the name you specify overrides the NIC renaming. So 
after following the instructions literally I wind up with "eth0" instead 
of "em1", because that's what I named the initscript and/or specified 
for the DEVICE value.

>> Once I renamed that script to ifcfg-eth0 (and changed the DEVICE value
>> in the file to match), all is well. It does indeed appear to be a
>> timing issue due to the "Predictable Network Interface Names" feature
>> and when its NIC name musical chairs dance begins.
> If there is a timing problem, then that is a bug. In udev? systemd?
> initscripts? I'm not sure...

It's a bug in architecture, in my opinion. The way it works causes a 
renaming of the devices in the middle of boot, so depending on where you 
need to instrument the boot code you will have to use a different name 
for the device. I'm sure that's also "predictable" if you understand in 
detail all the code involved.

On my system, I have two dual-ethernet cards (in adjacent slots) as well 
as the motherboard NIC. I get default names like (from memory - that 
machine is not available at the moment) em1, enp48s0, enp48s1, enp51s0, 
enp51s1. I certainly would not have predicted these names. For added 
fun, the default names created for the initscripts are different. For 
example for enp48s0 I have ifcfg-p48s0.

> Keep in mind, though, that the name of the ifcfg file is definitely
> insignificant, and it's possible that the DEVICE and NAME parameters in
> the ifcfg file may be ignored at times, as long as there is an HWADDR
> and/or uuid to key from.

The opposite appears to be true. The HWADDR is causing the match of the 
initscript, and the script and/or DEVICE name is being used to drive the 
final device name. So following the instructions literally actually 
works for me (and results in a different name for the NIC). There is one 
sentence in the fedoraproject.org URL I share below which provides a 
clue to this ("only as a fallback if the user/administrator did not 
manually assign names ... via the old networking scripts")

>> I have had more problems due to that one feature than anything else in
>> recent memory. It is a misnomer if ever there was one. Even the docs
>> related to it are incorrect (for Fedora 19, creating the symlink
>> described at
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>> doesn't have the expected result of disabling the feature).
> Are you sure that F19 has that form of netdev naming in the first place?
> The non-integrated netdevs on my F19 system have names based on their
> slot, e.g. "p4p2", not the type of names specified in the web page you
> reference above (e.g. "enp2s0"). Even my F20 system seems a bit up in
> the air - what had been called "wlan0" in F17 is now called "wlp3s0"
> (which seems like one of the new names), but an ExpressCard ethernet
> plugged into the system is still classified as "p3p1".

See my initial note about documentation not accurately describing the 
behavior. This is only the tip of the iceberg.

If you look here: 
http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
you find a close-but-no-cigar analog, which then references the 
freedesktop.org URL I mentioned extensively as if somehow it described 
the behavior. It does not. Another example - you cannot disable this 
feature by creating the udev/rules.d file documented.

In case you haven't guessed, I am totally disgusted with this feature. 
It is a blight upon the Linux landscape. I hardly know where to begin 
filing bugs but if I were to file one it would be titled something like 
"This feature is ill-conceived". Linux was better off without it. There 
is no practical way to know a-priori what name a hardware device may be 
assigned, and knowing the names does not help you determine which 
hardware NIC is referenced (except, perhaps, in the case of a 
motherboard NIC). How is that "predictable"? What value does it provide? 
It seems designed to create typos and carpal-tunnel syndrome.

</rant>

-Bob