Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
Thanks Ralph!
I don't think you can imagine how helpful your text explanation was.
Qemu documentation is a world of assumptions about the user,
conflicting docs, anecdotal solutions, ambiguity, and pretty much
anything except how the whole thing's put together. Your documentation
(quoted below) is by far the best in terms of explaining how the whole
thing fits together. THANK YOU!
Based on your explanation of how the bridge interface works, and how
-netdev user creates an IP level hack, and how id strings are used, I
quickly created the following qemu startup script:
#!/bin/sh
dvddir=/scratch/linuxinst/devuan/devuan_beowulf/installer-iso
qemu-system-x86_64 --enable-kvm \
-cdrom $dvddir/devuan_beowulf_3.0.0_amd64-desktop.iso \
-hda /scratch/qemu_images/beowulf.disk \
-m 4G \
-boot c \
-netdev bridge,id=mybridge0,br=br0 \
-device virtio-net-pci,netdev=mybridge0 \
The preceding shellscript produces a Devuan guest VM with the following
capabilities:
* Can ping, ssh, or web browse to 192.168.0.1, 192.168.0.2, 192.168.0.13
* Can ping, ssh or web browse to Troubleshooters.Com
* Can be pinged, ssh'ed or browsed from 192.168.0.2 or 192.168.0.97
* Appears much more performant than -netdev user
* Can ping (probably with help from some other procedures I did before)
* Can be run by user slitt (after making slitt a member of group
unpriv_ping)
* Requires no virt-manager, aqemu, brctl, etc.
In other words, my Devuan VM guest looks a hell of a lot like just
another metal machine on my 192.168.0.0/24 LAN. Which is what I wanted.
I still have tasks to complete:
* Convert it from DHCP to a fixed address without losing its
capabilities.
* Make the screen larger and focus easier to achieve
* Make keystrokes go to the Devuan VM guest instead of the Void metal
host.
* Achieve a remote GUI connection via ssh -Y or VNC.
* Making it run from user slitt inste
* Write documentation, which will require me backing out a lot of the
stuff I did to see which is necessary and which is anecdotal fluff.
I'm serious, once I read your documentation the solution became
obvious, requiring only a quick web lookup to determine exact syntax.
Thanks,
SteveT
On Sun, 21 Feb 2021 22:49:09 +1100
Ralph Ronnquist via Dng wrote:
> Networking for qemu is not that hard though better documentation is a
> praiseworthy aim. But there are an awful lot of variations both in
> what to achieve and in the ways in achieving it. These are some
> thoughts from me:
>
> Like for all qemu device emulations, the network setup arguments for
> qemu come in pairs:
> + one argument that declares the internal emulation device, and
> + another argument that declares to host side attachment.
>
> The connection between the two arguments is done by means of an
> identification label, where (for net emulation) the host attachment is
> "named" by the label using an "id=LABEL" option and the internal
> emulation device argument mentions it using a "netdev=LABEL" option,
> where thus the LABEL bit is your choosen name.
>
> If you leave out identifications then qemu makes guesses about how
> arguments go together; it invents labels "cleverly" and uses them
> "intelligently". Unfortunately most documentation relies on that
> hidden labelling and as a result things appear to work by magic.
>
> Further just for the sake of increased confusion, there is also an
> alternative combination or shortcut argument ("-nic") that lets you
> configure both the emulation and attachment in a single option
> collection.
>
> In your case you have declared a single internal device, the e1000,
> and linked that to one of the two host attachments by the label
> "mynet0". The other host attachment, "mybridge0", is dangling, i.e.
> not linked with any internal interface emulation device, which qemu
> advices about with the "no peer for mybridge0" warning.
>
> HOST SIDE ATTACHMENT
>
> The hands-on for the host side setup depends firstly on which type of
> host attachment it is. "user" and "bridge" are two host attachment
> types. The (currently) full list is
> "(tap|bridge|user|l2tpv3|vde|netmap|vhost-user|socket)".
>
> They are all configured in their own ways although typically they use
> the same or overlapping names of options with typically concordant
> uses of them. The qemu-system-x86 "man" page is rather good at
> describing the attachment types and their options.
>
> In my words:
>
> The "user" type attachment is a "pretend" attachment as it
> facilitates IP level networking for the guest without having
> networking presence as an actual host interface. There is little
> good to say about this attachment type except that it's the one to
> use if you don't want to know anything about anything. Well, not my
> preference at least. The "user" type attachment is especially
> peculiar as it includes a DHCP service for the guest with a client
>
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
Networking for qemu is not that hard though better documentation is a
praiseworthy aim. But there are an awful lot of variations both in
what to achieve and in the ways in achieving it. These are some
thoughts from me:
Like for all qemu device emulations, the network setup arguments for
qemu come in pairs:
+ one argument that declares the internal emulation device, and
+ another argument that declares to host side attachment.
The connection between the two arguments is done by means of an
identification label, where (for net emulation) the host attachment is
"named" by the label using an "id=LABEL" option and the internal
emulation device argument mentions it using a "netdev=LABEL" option,
where thus the LABEL bit is your choosen name.
If you leave out identifications then qemu makes guesses about how
arguments go together; it invents labels "cleverly" and uses them
"intelligently". Unfortunately most documentation relies on that
hidden labelling and as a result things appear to work by magic.
Further just for the sake of increased confusion, there is also an
alternative combination or shortcut argument ("-nic") that lets you
configure both the emulation and attachment in a single option
collection.
In your case you have declared a single internal device, the e1000,
and linked that to one of the two host attachments by the label
"mynet0". The other host attachment, "mybridge0", is dangling, i.e.
not linked with any internal interface emulation device, which qemu
advices about with the "no peer for mybridge0" warning.
HOST SIDE ATTACHMENT
The hands-on for the host side setup depends firstly on which type of
host attachment it is. "user" and "bridge" are two host attachment
types. The (currently) full list is
"(tap|bridge|user|l2tpv3|vde|netmap|vhost-user|socket)".
They are all configured in their own ways although typically they use
the same or overlapping names of options with typically concordant
uses of them. The qemu-system-x86 "man" page is rather good at
describing the attachment types and their options.
In my words:
The "user" type attachment is a "pretend" attachment as it
facilitates IP level networking for the guest without having
networking presence as an actual host interface. There is little
good to say about this attachment type except that it's the one to
use if you don't want to know anything about anything. Well, not my
preference at least. The "user" type attachment is especially
peculiar as it includes a DHCP service for the guest with a client
visible IP address for the host, even though the attachment is not
associated with an interface.
The "bridge" type attachment results in a host side tap interface
that get added to (and remove from) a nominated bridge or bridge
"br0" by default.
The "tap" type attachment results in a host side tap interface
seemingly without any bridge juggling. However, its default script
option nominates the /etc/qemu-ifup script which adds the tap to the
bridge, if any, nominated by a br option, or by default the bridge,
if any,that facilitates the default route for the host at the time
guest is started.
The "vde" type attachment is also a "pretend" attachment but it
facilitates full Ethernet level networking via VDE virtual
networking, which typically is present as a tap interface on the
host. In this case you set up a "VDE switch" with a tap, and then
make qemu connect up to that via the sock option which is
"/tmp/vde.ctl" by default (coincidentally the same as the default
setting for a VDE switch).
and so forth.
CLIENT SIDE
The hands-on for the client side is just normal network configuration.
which parimarily depends on whether to use DHCP (in part or full) or
static configuration.
With the "user" type attachment, the client is not a full networking
entity from the host (or outside) point of view as it only handles IP
level transport. Other attachment types makes the client a full
networking entity.
To use DHCP the overall setup must of course include a DHCP server on
the network of the host side attachment (or the built-in one of the
"user" type attachment).
etc.
Ralph.
On 21/02 03:08, Steve Litt wrote:
>
> On Thu, 18 Feb 2021 07:18:44 -0700
> Gabe Stanton via Dng wrote:
>
> > I'm sorry for the confusion. That was not the guide I used. I did find
> > the guide I used. It seems pretty straight forward, and I believe it
> > clears up all the confusion and questions caused by my previous email.
> >
> > https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network
>
> Thanks Gabe. The preceding link helped, but was not sufficient.
> Although better than most, it shares the same ambiguities as the
> others, including not telling whether they're referring to the metal
> host or the VM guest when discussing TAPs, bridges, devices and the
> like. Also, like most of the others, they don't specifically identify
> what should go in the "id=" slots.
>
> Based
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Thu, 18 Feb 2021 07:18:44 -0700
Gabe Stanton via Dng wrote:
> I'm sorry for the confusion. That was not the guide I used. I did find
> the guide I used. It seems pretty straight forward, and I believe it
> clears up all the confusion and questions caused by my previous email.
>
> https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network
Thanks Gabe. The preceding link helped, but was not sufficient.
Although better than most, it shares the same ambiguities as the
others, including not telling whether they're referring to the metal
host or the VM guest when discussing TAPs, bridges, devices and the
like. Also, like most of the others, they don't specifically identify
what should go in the "id=" slots.
Based on the preceding link, I deduce that the TAP is created by the
guest VM, in such a way that it attaches to the bridge created on the
metal host, and therefore I have no need to create a TAP on the metal
host.
Here's my progress so far, based on the link you supply above and my
other readings and experimentation:
***
I build the bridge purely with ip commands. Also, I don't mess
with the firewall (which perhaps has been my problem all along). I'll
investigate this tomorrow.
Below are some scripts and stuff I'm using. The following is
upnet.sh, which I use to set up networking on the metal host, which
happens to run Void Linux, which has no /etc/network/interfaces:
=
#!/bin/sh
use_bridge=1
use_tap=0
dev="enp40s0"
ipaddr_major="192.168.0.2"
ipaddr_minor="192.168.0.102"
gateway="192.168.0.1"
error_tap_without_bridge(){
echo -n "ERROR: Can\'t set TAP without "
echo -n "BRIDGE! "
echo Aborting...
exit 1
}
enable_ip_forwarding(){
echo 1 > /proc/sys/net/ipv4/ip_forward
}
unset_everything(){
dev=$1
ip_maj=$2
ip_min=$3
gateway=$4
echo "Unsetting everything for $dev, $ip_maj and $ip_min"
ip link set dev tap0 down
brctl delif br0 tap0
ip link del tap0
ip link set dev br0 down
ip addr del $ip_min/24 dev br0
ip addr del $ip_maj/24 dev br0
brctl delbr br0
ip link set dev $dev down
ip addr del $ip_min/24 dev $dev
ip addr del $ip_maj/24 dev $dev
echo ""
}
set_hostname_and_localhost(){
echo "Setting hostname and localhost"
hostname=`grep -v "^\s*#" /etc/hostname | head -n1`
ip link set dev lo up
echo ""
}
create_phys_device_link(){
dev=$1
echo Creating device link for $dev
ip link set dev $dev up
echo ""
}
set_phys_device_addr(){
dev=$1
ip_maj=$2
ip_min=$3
gateway=$4
echo -n "Setting physical device addresses "
echo -n "$ip_maj "
echo -n "and $ip_min "
echo -n "for $physdev "
echo "with gateway $gateway"
ip link set dev $dev down
ip addr add $ip_maj/24 dev $dev
ip addr add $ip_min/24 dev $dev
ip link set dev $dev up
ip route add default via $gateway
echo ""
}
set_bridge(){
dev=$1
ip_maj=$2
ip_min=$3
gateway=$4
echo Setting bridge for $dev
echo -n "Creating and setting bridge addresses "
echo -n "$ip_maj "
echo -n "and $ip_min "
echo -n "for $physdev "
echo "with gateway $gateway"
ip link add name br0 type bridge
ip link set dev $dev master br0
ip addr add $ip_maj/24 dev br0
ip addr add $ip_min/24 dev br0
ip link set dev br0 up
ip route add default via $gateway
echo ""
}
set_tap(){
echo Setting tap
ip tuntap add tap0 mode tap
brctl addif br0 tap0
#ip addr add 192.168.0.66/24 dev tap0
ip link set dev tap0 up
echo ""
}
show_networking(){
echo -n "Networking follows in 3 seconds..."
sleep 3
echo "\n"
echo ""
echo ""
ip -4 link
echo ".."
ip -4 addr
echo ".."
ip -4 route
echo ""
echo ""
}
echo "\nBegin upnet.sh"
[ "$use_tap" = "1" ] && [ "$use_bridge" != "1" ] && \
error_tap_without_bridge
unset_everything $dev $ipaddr_major $ipaddr_minor $gateway
enable_ip_forwarding
set_hostname_and_localhost
create_phys_device_link $dev $ipaddr_major $ipaddr_minor $gateway
[ "$use_bridge" = "1" ] || \
set_phys_device_addr $dev $ipaddr_major $ipaddr_minor $gateway
[ "$use_bridge" = "1" ] && set_bridge $dev \
$ipaddr_major $ipaddr_minor $gateway
[ "$use_tap" = "1" ] && \
set_tap $dev $ipaddr_major $ipaddr_minor $gateway
show_networking
=
The preceding just builds br0 with ip addresses 192.168.0.2 and
192.168.0.102, default route (gateway) 192.168.0.1, for my metal host,
and runs every time my metal host is rebooted (or it can be run any
time). It has provisions to build a tap, or to not build a bridge and
instead assign the IP addresses and default route to enp40s0 itself.
The next shellscript runs on my metal host to launch a (Devuan) VM
guest:
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Thu, 2021-02-18 at 05:30 -0500, Steve Litt wrote: > 1) Is the following /etc/network/interfaces on the guest, or on > thehost? > 2) If on the guest, do I need to have the "gateway" part of the > br0iface be an address *other* than the gateway the host and rest of > theLAN uses? > 3) Is a TAP needed anywhere? Do I need to make provisions for it > (andif so, where) > 4) If the TAP is needed, do I have to make , or does the guest make > theTAP and set it up? > > > auto loiface lo inet loopback > > # The primary network interfaceauto eth0 > > #make sure we don't get addresses on our raw deviceiface eth0 inet > > manualiface eth0 inet6 manual > > #set up bridge and give it a static ipauto br0iface br0 inet > > static address 192.168.1.2 netmask > > 255.255.255.0 network 192.168.1.0 broadcast > > 192.168.1.255 gateway 192.168.1.1 bridge_ports > > eth0 bridge_stp off bridge_fd 0 > > bridge_maxwait 0 dns-nameservers 8.8.8.8 > > #allow autoconf for ipv6iface br0 inet6 auto accept_ra > > 1Once that is correctly configured, you should beable to use the > > bridge on new VM deployments with: > > virt-install --network bridge=br0 [...] > > That last line looks like you're not using TAP at all. Is that true? > What goes between the square brackets? > Thanks, > SteveT I'm sorry for the confusion. That was not the guide I used. I did find the guide I used. It seems pretty straight forward, and I believe it clears up all the confusion and questions caused by my previous email. https://www.debian.org/doc/manuals/debian-handbook/sect.virtualization.en.html#sect.lxc.network 12.2.2.2. Network Configuration The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required. The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following: auto eth0 iface eth0 inet dhcp They should be disabled and replaced with the following: #auto eth0 #iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge-ports eth0 The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical eth0 as well as the interfaces defined for the containers. In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world. Less important but possibly relevant or helpful info is that, although the guide above is for lxc, I don't use lxc but kvm, and the kvm install instructions link back to the lxc networking section on the same page. That's why I got confused and sent the wrong guide. I'll stop with the irrelevant stuff now lol. Glad to offer any more assistance or info I can. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Wed, 17 Feb 2021 16:28:16 -0700 Gabe Stanton via Dng wrote: > On Wed, 2021-02-17 at 16:28 -0500, Steve Litt wrote: > > Hi Gabe, > > On your guest VM, what does it say your default route is when > > youperform the ip route command? > > results of ip route: > > default via 192.168.1.1 dev eth0 > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.75 > > > > Did you need to do something special to get that default > > route(gateway)? > > Thanks, > > SteveT > > I believe I used the below from here, as well as the 'set up a bridge' > link and maybe the 'QEMU' page linked. > > I thought I had started keeping better notes about what I do... I must > have started that after I installed this VM lol. > > > > > source url (same as above label'd "here"): > https://wiki.debian.org/KVM?highlight=%28%5CbCategoryVirtualization%5Cb%29#Setting_up_bridge_networking > Between VM host, guests and the world > In order to let communications between host, guests and outside world, > you may set up a bridge and as described at QEMU page. > For > example, you can modify the network configuration file > /etc/network/interfaces to setup the ethernet interface eth0 to a > bridge > interface br0 similar as below. After the configuration, you can > set using Bridge Interface br0 as the network connection in VM guest > configuration. 1) Is the following /etc/network/interfaces on the guest, or on the host? 2) If on the guest, do I need to have the "gateway" part of the br0 iface be an address *other* than the gateway the host and rest of the LAN uses? 3) Is a TAP needed anywhere? Do I need to make provisions for it (and if so, where) 4) If the TAP is needed, do I have to make , or does the guest make the TAP and set it up? > auto lo > iface lo inet loopback > > # The primary network interface > auto eth0 > > #make sure we don't get addresses on our raw device > iface eth0 inet manual > iface eth0 inet6 manual > > #set up bridge and give it a static ip > auto br0 > iface br0 inet static > address 192.168.1.2 > netmask 255.255.255.0 > network 192.168.1.0 > broadcast 192.168.1.255 > gateway 192.168.1.1 > bridge_ports eth0 > bridge_stp off > bridge_fd 0 > bridge_maxwait 0 > dns-nameservers 8.8.8.8 > > #allow autoconf for ipv6 > iface br0 inet6 auto > accept_ra 1Once that is correctly configured, you should be > able to use the bridge on new VM deployments with: > > virt-install --network bridge=br0 [...] That last line looks like you're not using TAP at all. Is that true? What goes between the square brackets? Thanks, 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] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Wed, 2021-02-17 at 16:28 -0500, Steve Litt wrote: > Hi Gabe, > On your guest VM, what does it say your default route is when > youperform the ip route command? results of ip route: default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.75 > Did you need to do something special to get that default > route(gateway)? > Thanks, > SteveT I believe I used the below from here, as well as the 'set up a bridge' link and maybe the 'QEMU' page linked. I thought I had started keeping better notes about what I do... I must have started that after I installed this VM lol. source url (same as above label'd "here"): https://wiki.debian.org/KVM?highlight=%28%5CbCategoryVirtualization%5Cb%29#Setting_up_bridge_networking Between VM host, guests and the world In order to let communications between host, guests and outside world, you may set up a bridge and as described at QEMU page. For example, you can modify the network configuration file /etc/network/interfaces to setup the ethernet interface eth0 to a bridge interface br0 similar as below. After the configuration, you can set using Bridge Interface br0 as the network connection in VM guest configuration. auto lo iface lo inet loopback # The primary network interface auto eth0 #make sure we don't get addresses on our raw device iface eth0 inet manual iface eth0 inet6 manual #set up bridge and give it a static ip auto br0 iface br0 inet static address 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports eth0 bridge_stp off bridge_fd 0 bridge_maxwait 0 dns-nameservers 8.8.8.8 #allow autoconf for ipv6 iface br0 inet6 auto accept_ra 1Once that is correctly configured, you should be able to use the bridge on new VM deployments with: virt-install --network bridge=br0 [...] Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Wed, 17 Feb 2021 11:43:56 -0700 Gabe Stanton via Dng wrote: > On Wed, 2021-02-17 at 11:26 -0700, Gabe Stanton via Dng wrote: > > On Tue, 2021-02-16 at 07:55 -0500, Steve Litt wrote: > > > Thanks Ralph, > > > I had left them both out, but putting them in didn't change > > > thesymptom. I tried with only auto eth0, and that didn't change > > > thesymptom either. > > > Thanks, > > > SteveT > > > Steve Litt > > > > > > Just want to throw this out there in case it helps even a bit. > > > > I have a devuan vm running on a devuan host, I believe virt-manager > > handled network setup for me, but in any case, below are the > > contents of my /etc/network/interfaces files from both the host and > > the vm. (notice on the host they have br0 config'd here instead of > > eth0, don't know if you were referring to that file on the host or > > the VM.) > > > > Host: > > > > auto br0 > > iface br0 inet dhcp > > bridge-ports eth0 > > > > > > > > > > > > VM: > > # This file describes the network interfaces available on your > > system # and how to activate them. For more information, see > > interfaces(5). > > > > source /etc/network/interfaces.d/* > > > > # The loopback network interface > > auto lo > > iface lo inet loopback > > > > # The primary network interface > > allow-hotplug eth0 > > iface eth0 inet dhcp > > > > > > > > > > anyway, hope that helps. > > > > Gabe > > > > > > > > > > ___Dng mailing > > list...@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > Just to be clear, my VM ip address is as you would like yours to be, > it is a dhcp address from the pool on my router. So my host is > 192.168.1.x and my vm is 192.168.1.y, and the VM is accessible from > the network. Hi Gabe, On your guest VM, what does it say your default route is when you perform the ip route command? Did you need to do something special to get that default route (gateway)? Thanks, 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] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Wed, 2021-02-17 at 11:26 -0700, Gabe Stanton via Dng wrote: > On Tue, 2021-02-16 at 07:55 -0500, Steve Litt wrote: > > Thanks Ralph, > > I had left them both out, but putting them in didn't change > > thesymptom. I tried with only auto eth0, and that didn't change > > thesymptom either. > > Thanks, > > SteveT > > Steve Litt > > > Just want to throw this out there in case it helps even a bit. > > I have a devuan vm running on a devuan host, I believe virt-manager > handled network setup for me, but in any case, below are the contents > of my /etc/network/interfaces files from both the host and the vm. > (notice on the host they have br0 config'd here instead of eth0, > don't know if you were referring to that file on the host or the VM.) > > Host: > > auto br0 > iface br0 inet dhcp > bridge-ports eth0 > > > > > > VM: > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > source /etc/network/interfaces.d/* > > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet dhcp > > > > > anyway, hope that helps. > > Gabe > > > > > ___Dng mailing > list...@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Just to be clear, my VM ip address is as you would like yours to be, it is a dhcp address from the pool on my router. So my host is 192.168.1.x and my vm is 192.168.1.y, and the VM is accessible from the network. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Tue, 2021-02-16 at 07:55 -0500, Steve Litt wrote: > Thanks Ralph, > I had left them both out, but putting them in didn't change > thesymptom. I tried with only auto eth0, and that didn't change > thesymptom either. > Thanks, > SteveT > Steve Litt Just want to throw this out there in case it helps even a bit. I have a devuan vm running on a devuan host, I believe virt-manager handled network setup for me, but in any case, below are the contents of my /etc/network/interfaces files from both the host and the vm. (notice on the host they have br0 config'd here instead of eth0, don't know if you were referring to that file on the host or the VM.) Host: auto br0iface br0 inet dhcp bridge-ports eth0 VM:# This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interfaceauto loiface lo inet loopback # The primary network interfaceallow-hotplug eth0iface eth0 inet dhcp anyway, hope that helps. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Tue, 16 Feb 2021 18:39:50 + g4sra via Dng wrote: > ‐‐‐ Original Message ‐‐‐ > On Tuesday, February 16, 2021 12:55 PM, Steve Litt > wrote: > > > On Tue, 16 Feb 2021 20:29:46 +1100 > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > > > On 16/02 03:24, Steve Litt wrote: > > > > > > > Hi all, > > > > My ultimate goal is to have a Devuan VM guest on my Void Linux > > > > Daily Driver Desktop (DDD) that acts like just another metal > > > > computer on my LAN at 192.168.0.0/24. I want it to have address > > > > 192.168.0.66. I've tried to do this sporadically over the past > > > > 2 years, never with success. ... > > > > I tried setting the VM guest's /etc/network/interfaces to static > > > > with address 192.168.0.66, with the gateway, netmask etc set > > > > accordingly, but after doing that, ip addr on the VM showed no > > > > IP address at all. > > > > > > It all looks fine, and static setup should work. Possibly you > > > left out the "auto eth0" or "allow-hotplug eth0" line? > > > > Thanks Ralph, > > > > I had left them both out, but putting them in didn't change the > > symptom. I tried with only auto eth0, and that didn't change the > > symptom either. > > > > Thanks, > > > > SteveT > > I gave up doing things this way as Qemu kept changing under me, > voiding my scripts. I now use 'virt-manager' relatively painlessly. Thanks g4sra, I tried virt-manager but became disallusioned. First, a look at the man page told me that although virt-manager can be used without systemd, systemd is invading. Worse, you can't use virt-manager without dbus. I consider dbus the ultimate anti-encapsulation thing ever invented: On troubleshooting, you have to chase *everything* through dbus. When encountering a "no dbus" error with virt-manager, I found out that I'd never run the dbus daemon, which is why every time I start LXDE on a Void Linux machine, I get a "no dbus" error, which I always just ignored. Also, even after I ran the dbus daemon, virt-manager didn't work. I'd have troubleshot it, but at that point I figured if I were going to troubleshoot anything, it would be pure qemu, because the end result would be a script that would work every time, not a set of clicks. This is also the reason I didn't run Gnome-Boxes or VirtualBox. > > That IP may have been issued by a Qemu dhcp server. Yes. > The first step is to confirm Qemu is not messing with stuff it > shouldn't... Spin up the VM and confirm that your host network > settings have not been altered/added to. You must do this when the VM > is running. I've read that tap devices are DOWN until something actually uses them. But yeah, I'll do an ip link and ip addr before, and after I run the qemu guest, and do a diff on the results. That should shed some light on it. Thanks for the suggestion! 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] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On 16/02 07:55, Steve Litt wrote: > > On Tue, 16 Feb 2021 20:29:46 +1100 > Ralph Ronnquist via Dng wrote: > > > On 16/02 03:24, Steve Litt wrote: > > > Hi all, > > > > > > My ultimate goal is to have a Devuan VM guest on my Void Linux Daily > > > Driver Desktop (DDD) that acts like just another metal computer on > > > my LAN at 192.168.0.0/24. I want it to have address 192.168.0.66. > > > I've tried to do this sporadically over the past 2 years, never > > > with success. ... > > > > > > I tried setting the VM guest's /etc/network/interfaces to static > > > with address 192.168.0.66, with the gateway, netmask etc set > > > accordingly, but after doing that, ip addr on the VM showed no IP > > > address at all. > > > > It all looks fine, and static setup should work. Possibly you left out > > the "auto eth0" or "allow-hotplug eth0" line? > > Thanks Ralph, > > I had left them both out, but putting them in didn't change the > symptom. I tried with only auto eth0, and that didn't change the > symptom either. Peculiar :) Yes, "auto eth0" would be right for telling ifupdown that the interface should be brought up during (post-pivot) boot, and all in all /etc/network/interfaces would have the following as the only configruations for eth0: auto eth0 iface eth0 inet static address 192.168.0.66/24 gateway 192.168.0.1 The previous setting that gives VM 10.0.2.15 would have been caused by a DHCP configuration, like: auto eth0 iface eth0 inet dhcp or by having some other networking tool such as wicd running. One way or the other it would have started a dhcp client that requests an address assignment via UDP broadcast, and something (either a dhcp service on DDD or on the network outside DDD) responded to offer 10.0.2.15 for the VM. If that client was a networking tool such as wicd then possibly that is still running and it now competes about the confgiuration of eth0 with ifupdown. Usually though it (wicd) would be more insistant and eventually take over, so you should then end up with a 10.0.2.0/24 address eventually, with some period of an unconfigured network. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
‐‐‐ Original Message ‐‐‐ On Tuesday, February 16, 2021 12:55 PM, Steve Litt wrote: > On Tue, 16 Feb 2021 20:29:46 +1100 > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > On 16/02 03:24, Steve Litt wrote: > > > > > Hi all, > > > My ultimate goal is to have a Devuan VM guest on my Void Linux Daily > > > Driver Desktop (DDD) that acts like just another metal computer on > > > my LAN at 192.168.0.0/24. I want it to have address 192.168.0.66. > > > I've tried to do this sporadically over the past 2 years, never > > > with success. ... > > > I tried setting the VM guest's /etc/network/interfaces to static > > > with address 192.168.0.66, with the gateway, netmask etc set > > > accordingly, but after doing that, ip addr on the VM showed no IP > > > address at all. > > > > It all looks fine, and static setup should work. Possibly you left out > > the "auto eth0" or "allow-hotplug eth0" line? > > Thanks Ralph, > > I had left them both out, but putting them in didn't change the > symptom. I tried with only auto eth0, and that didn't change the > symptom either. > > Thanks, > > 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 I gave up doing things this way as Qemu kept changing under me, voiding my scripts. I now use 'virt-manager' relatively painlessly. That IP may have been issued by a Qemu dhcp server. The first step is to confirm Qemu is not messing with stuff it shouldn't... Spin up the VM and confirm that your host network settings have not been altered/added to. You must do this when the VM is running. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On Tue, 16 Feb 2021 20:29:46 +1100 Ralph Ronnquist via Dng wrote: > On 16/02 03:24, Steve Litt wrote: > > Hi all, > > > > My ultimate goal is to have a Devuan VM guest on my Void Linux Daily > > Driver Desktop (DDD) that acts like just another metal computer on > > my LAN at 192.168.0.0/24. I want it to have address 192.168.0.66. > > I've tried to do this sporadically over the past 2 years, never > > with success. ... > > > > I tried setting the VM guest's /etc/network/interfaces to static > > with address 192.168.0.66, with the gateway, netmask etc set > > accordingly, but after doing that, ip addr on the VM showed no IP > > address at all. > > It all looks fine, and static setup should work. Possibly you left out > the "auto eth0" or "allow-hotplug eth0" line? Thanks Ralph, I had left them both out, but putting them in didn't change the symptom. I tried with only auto eth0, and that didn't change the symptom either. Thanks, 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] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
On 16/02 03:24, Steve Litt wrote: > Hi all, > > My ultimate goal is to have a Devuan VM guest on my Void Linux Daily > Driver Desktop (DDD) that acts like just another metal computer on my > LAN at 192.168.0.0/24. I want it to have address 192.168.0.66. I've > tried to do this sporadically over the past 2 years, never with success. > ... > > I tried setting the VM guest's /etc/network/interfaces to static with > address 192.168.0.66, with the gateway, netmask etc set accordingly, > but after doing that, ip addr on the VM showed no IP address at all. It all looks fine, and static setup should work. Possibly you left out the "auto eth0" or "allow-hotplug eth0" line? Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Assigning a specific subnet and address to a Devuan Beowulf Qemu guest
Hi all, My ultimate goal is to have a Devuan VM guest on my Void Linux Daily Driver Desktop (DDD) that acts like just another metal computer on my LAN at 192.168.0.0/24. I want it to have address 192.168.0.66. I've tried to do this sporadically over the past 2 years, never with success. Here's how far I've gotten: I have a shellscript called upnet.sh that sets up networking on my DDD, which has no /etc/network/interfaces and instead requires commands to set up the network. It also sets up network bridge br0 and tap tap0. It is shown immediately below: #!/bin/sh # MAKE SURE IP FORWARDING IS ENABLED echo 1 > /proc/sys/net/ipv4/ip_forward # DEAL WITH HOSTNAME AND LOCALHOST hostname=`grep -v "^\s*#" /etc/hostname | head -n1` ip link set dev lo up # UNDO ANY POSSIBLE STUFF FROM PREVIOUS UPNET.SH ip link set dev tap0 down brctl delif br0 tap0 ip link set dev br0 down ip addr del 192.168.0.102/24 dev br0 ip addr del 192.168.0.2/24 dev br0 brctl delbr br0 ip link set dev enp40s0 down ip addr del 192.168.0.102/24 dev enp40s0 ip addr del 192.168.0.2/24 dev enp40s0 # BRING UP enp40s0 ip link set dev enp40s0 up ### GET br0 UP AND RUNNING WITH RIGHT IP ADDRESSES ip link add name br0 type bridge ip link set dev enp40s0 master br0 ip addr add 192.168.0.2/24 dev br0 ip addr add 192.168.0.102/24 dev br0 ip link set dev br0 up ip route add default via 192.168.0.1 ### DO THE TUN/TAP STUFF ip tuntap add tap0 mode tap brctl addif br0 tap0 ip link set dev tap0 up The ip link, ip addr, and ip route commands shows this works perfectly on my DDD. The shellscript that runs my Devuan VM follows: #!/bin/sh dvddir=/scratch/linuxinst/devuan/devuan_beowulf/installer-iso qemu-system-x86_64 -m 1024 \ -hda beowulf.disk \ -cdrom $dvddir/devuan_beowulf_3.0.0_amd64-desktop.iso \ -boot c -ctrl-grab -cpu max -vga std -enable-kvm \ -net nic,model=virtio,macaddr=00:00:00:00:00:01 -net tap,ifname=tap0 The resulting Devuan VM guest works just fine, can ssh to my LAN computers, can ssh to my Internet host, but it's still 10.0.2.15 with default route 10.0.2.2. I want it 192.168.0.66 with default route 192.168.0.1. I tried setting the VM guest's /etc/network/interfaces to static with address 192.168.0.66, with the gateway, netmask etc set accordingly, but after doing that, ip addr on the VM showed no IP address at all. I feel like I'm closer than I've ever been before, but I'm not there yet. How do I set up my Devuan VM guest to 192.168.0.66, with proper gateway, etc, so it can be just another computer on my 192.168.0.0/24 LAN? Thanks, 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
