:: Re: [DNG] Assigning a specific subn…
Kezdőlap
Delete this message
Reply to this message
Szerző: Gabe Stanton
Dátum:  
Címzett: dng
Tárgy: 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