:: Re: [DNG] My Qemu LAN-peer document…
Top Page
Delete this message
Reply to this message
Author: tito
Date:  
To: dng
Subject: Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 01:34:40 +1100
Ralph Ronnquist via Dng <dng@???> wrote:

> On 02/03 14:29, tito wrote:
> > On Wed, 3 Mar 2021 00:06:27 +1100
> > Ralph Ronnquist via Dng <dng@???> 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.