On Wed, 3 Mar 2021 01:34:40 +1100 Ralph Ronnquist via Dng <[email protected]> wrote:
> On 02/03 14:29, tito wrote: > > On Wed, 3 Mar 2021 00:06:27 +1100 > > Ralph Ronnquist via Dng <[email protected]> wrote: > > > > > On 02/03 06:48, Steve Litt wrote: > > > > Hi all, > > > > > > > > As you know, I was asking many Qemu LAN-peer questions on this > > > > list a week ago. My documentation on the subject has finally > > > > achieved first-draft status. If you'd like to see it, go to: > > > > > > > > http://troubleshooters.com/linux/qemu/nobs.htm > > > > > > Thank you for the dedication :) > > > > > > The following are three specific comments to your write-up: > > > > > > 1) Re the name "eth0" of the VM guest network interface; this > > > name is invented by the kernel module that gets loaded by the > > > kernel upon discovery of the hardware unit. It's not a Qemu > > > naming; it's the Linux kernel (module). > > > > > > Afaik, all Ethernet kernel modules will name the adapters they > > > discover in the "ethN" series of names, and there is no way to > > > tell them to do something else. > > > > > > But the hotplug handling subsystem comes in later, i.e. after > > > that the adapter has been registered with the kernel name, and > > > possibly renames the adapter as per the one or the other funnily > > > named naming scheme. That is for instance how your Void Linux > > > ends up with the name "enp42s0". > > > > > > The intended default in Devuan is to *not* rename the adapater in > > > the hotplug subsystem (aka udev or eudev) but rather retain the > > > name that the module assigned. Of course, it's still possible to > > > have hotplug code (aka rules) to rename the adapters, but that's > > > not the intended default in Devuan. > > > > > > Note: I say "intended default" because any particular installation > > > typically has further layers of software that also might bring in > > > hotplug handling deviations that implements a different "local > > > default". > > > > Hi, > > nonetheless even in devuan you have no guarantee that your > > network interface will come up always with the same name > > (unless you have only one) as bios quirks and pnp enumeration > > can change the order of network interface discovery and thus > > their naming. > > > > Ciao, > > Tito > > > ... > > Yes that is true for bare-metal hardware. But I think that in a Qemu > emulation the device order is fully determinstic and therefore that > randomness doesn't come up. > > For bare-metal hardware I believe there is a first possible "race" > between different modules (that handle different card types), and a > second possible "race" for multiple same-type cards, which are handled > by the one and same module. Yep, experienced all of them mixed in various manners on my routers same module race different modules race onboard and addon cards race > In theory each and every actual network device should have a globally > unique MAC address, and for that reason one might want the adapter > names to be functionally dependent on that, so as to have any one > actual device always have the same adapter name (when it comes to > networking configuration time). > > The crux for that is that renaming happens in hotplug handling or > later. I.e. each card will be renamed after having got an initial > module-assigned name, and also at that time any other card may have at > random either their initial module-assigned name or their name after > renaming. And of course, an interface may only be renamed if > unconfigured. I would add that renaming of multiple cards/ports works only if you rename all of them to a different intermediate name and then back to wanted name and order otherwise renaming can fail because the name is already assigned to another card/port. Ciao, Tito > Ralph. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
