Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Le 03/03/2021 à 08:04, tito via Dng a écrit : >> Am I hearing correctly when I think you two are saying I can make >> multiple network devices have determinate names (even if I don't >> select those names) by doing something with their MAC addresses? If >> so, how do I do it? >> >> SteveT >> >> Steve Litt >> Autumn 2020 featured book: Thriving in Tough Times >> http://www.troubleshooters.com/thrive > Hi, > you can set the device names by MAC addresses at boot > and in the past it worked as udev/eudev net-persisent-name.rules > (but seems to be broken, optimized out nowadays). I love this expression, "optimised out". To stay in the same style, I consider the result of this intended "optimisation" as definitely "suboptimal" (~: -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 01:06:55 -0500 Steve Litt wrote: > > On Wed, 3 Mar 2021 13:06:45 +1100 > Ralph Ronnquist via Dng wrote: > > > On 03/03 00:19, g4sra via Dng wrote: > > > ‐‐‐ Original Message ‐‐‐ > > > On Wednesday, March 3, 2021 12:15 AM, spiralofhope > > > wrote: > > > > On Wed, 3 Mar 2021 01:34:40 +1100 > > > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > > > 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. > > > > > > > I've always found this strange.. > > > > > > > Is there nothing like hard drives' UUID? > > > > > > Yes, MAC Addresses. > > > Sysadmins are just generally too lazy to use them. > > > > Well, this is really a fundamental problem, the "das ding an sich" > > that Kant brought up some few years ago to the merriment and > > pleasure of his contemporary philosphical minded peers. > > > > But yes, MAC address for network interfaces are alike UUID for > > partitions in that they are used for identifing the *functions* of > > devices so that further configurations can be made with respect to > > those identifications regardless of which actual, physical device > > implements them (the functions). > > Am I hearing correctly when I think you two are saying I can make > multiple network devices have determinate names (even if I don't > select those names) by doing something with their MAC addresses? If > so, how do I do it? > > SteveT > > Steve Litt > Autumn 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive Hi, you can set the device names by MAC addresses at boot and in the past it worked as udev/eudev net-persisent-name.rules (but seems to be broken, optimized out nowadays). Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 13:06:45 +1100 Ralph Ronnquist via Dng wrote: > On 03/03 00:19, g4sra via Dng wrote: > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, March 3, 2021 12:15 AM, spiralofhope > > wrote: > > > On Wed, 3 Mar 2021 01:34:40 +1100 > > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > > 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. > > > > > I've always found this strange.. > > > > > Is there nothing like hard drives' UUID? > > > > Yes, MAC Addresses. > > Sysadmins are just generally too lazy to use them. > > Well, this is really a fundamental problem, the "das ding an sich" > that Kant brought up some few years ago to the merriment and pleasure > of his contemporary philosphical minded peers. > > But yes, MAC address for network interfaces are alike UUID for > partitions in that they are used for identifing the *functions* of > devices so that further configurations can be made with respect to > those identifications regardless of which actual, physical device > implements them (the functions). Am I hearing correctly when I think you two are saying I can make multiple network devices have determinate names (even if I don't select those names) by doing something with their MAC addresses? If so, how do I do it? SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On 03/03 00:19, g4sra via Dng wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, March 3, 2021 12:15 AM, spiralofhope > wrote: > > > On Wed, 3 Mar 2021 01:34:40 +1100 > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > 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. > > > I've always found this strange.. > > > Is there nothing like hard drives' UUID? > > Yes, MAC Addresses. > Sysadmins are just generally too lazy to use them. Well, this is really a fundamental problem, the "das ding an sich" that Kant brought up some few years ago to the merriment and pleasure of his contemporary philosphical minded peers. But yes, MAC address for network interfaces are alike UUID for partitions in that they are used for identifing the *functions* of devices so that further configurations can be made with respect to those identifications regardless of which actual, physical device implements them (the functions). The same function (e.g. partition) can then be transferred to a different physical device without needing to change those configurations. Between a physical device and the function you find the adapter, which implements actual device control and makes the device be of a class, so that software can access it by virtue of a class API. The names "eth0" and such then corresponds to the disk adapter naming like "sda" and such; they are identification labels for the adapters rather than for the actual devices that the adapters operate on. I think Lewis Carroll had a stab at this issue as well in "Through The Looking Glass" where the name of the Black Knight was called something... or how it was. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
‐‐‐ Original Message ‐‐‐ On Wednesday, March 3, 2021 12:15 AM, spiralofhope wrote: > On Wed, 3 Mar 2021 01:34:40 +1100 > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > 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. > > I've always found this strange.. > > Is there nothing like hard drives' UUID? > Yes, MAC Addresses. Sysadmins are just generally too lazy to use them. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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 wrote: > 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. I've always found this strange.. Is there nothing like hard drives' UUID? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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 wrote: > On 02/03 14:29, tito wrote: > > On Wed, 3 Mar 2021 00:06:27 +1100 > > Ralph Ronnquist via 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. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/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 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. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 00:06:27 +1100 Ralph Ronnquist via 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 > > 2) Re VM client gateway with DHCP configuration. This belongs to the > (default) configuration of the DHCP client daemon on the VM client. > That configuration, in /etc/dhcp/dhclient.conf, includes the setting > to ask for the "router" from the DHCP service, which in itself has a > configuration of this, i.e. which router to tell the client(s) to use. > > The normal setup for that is that the router also provides the DHCP > service and thus is configured to nominate itself as networking > gateway. > > 3) Re specifying the physical device on the host to connect to the > bridge; when using the "bridge" type netdev setup it will create a tap > device with an invented name, and afaik there is no easy way to play > with that one. It is automatic and hidden, but if a tap of the > invented name happens to exist already then it will be used. > > If you instead use the "tap" type netdev setup you may specify the > names of both the tap (to create unless pre-existing) and bridge > (pre-existing) in the parameters. > > regards, > > Ralph. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
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". 2) Re VM client gateway with DHCP configuration. This belongs to the (default) configuration of the DHCP client daemon on the VM client. That configuration, in /etc/dhcp/dhclient.conf, includes the setting to ask for the "router" from the DHCP service, which in itself has a configuration of this, i.e. which router to tell the client(s) to use. The normal setup for that is that the router also provides the DHCP service and thus is configured to nominate itself as networking gateway. 3) Re specifying the physical device on the host to connect to the bridge; when using the "bridge" type netdev setup it will create a tap device with an invented name, and afaik there is no easy way to play with that one. It is automatic and hidden, but if a tap of the invented name happens to exist already then it will be used. If you instead use the "tap" type netdev setup you may specify the names of both the tap (to create unless pre-existing) and bridge (pre-existing) in the parameters. regards, Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] My Qemu LAN-peer documentation is now in its first draft
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 SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
