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.