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. 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. 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/PredictableNetworkInterf... doesn't have the expected result of disabling the feature). Thanks, Bob On 11/12/2013 10:17 AM, Bob Doolittle wrote:

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: 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. 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. 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") 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/SystemdPredictableNetworkInterface... 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