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
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
