:: Re: [DNG] My Qemu LAN-peer document…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Ralph Ronnquist
Ημερομηνία:  
Προς: dng
Αντικείμενο: Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
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.

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.

Ralph.