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