:: Re: [DNG] My Qemu LAN-peer document…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: tito
Ημερομηνία:  
Προς: 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 <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@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng