[gentoo-user] low risk network bridge

[gentoo-user] low risk network bridge

[Stefan G. Weichinger]

My task is to enable a (remote) server to run VMs via qemu/KVM.

The server is configured to set up its eth0 via openrc but this isn't 
enough to run the VMs network.

I tried macvtap but something didn't work, either libvirt (yes, with 
USE-flag "macvtap") or something else (the kernel supports mavtap).

So bridging.

I'd like to keep the risk of losing connectivity as low as possible ... 
I can visit the place in a few weeks to iron out things but I would like 
to set up a bridge now without failure, just to get that VM running asap.

Could anyone advise me in doing this?

I have only ssh-access now ... its openrc-driven, and I might use a 
second IPv4-IP if that helps ...

anyone?

(editing the conf.d-files to remove eth0 and setup br0 is too scary 
right now. One mistake and the box is offline)

Re: [gentoo-user] low risk network bridge

[Poison BL.]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

On Wed, May 6, 2015 at 3:59 PM, Stefan G. Weichinger <lists@xunil.at> wrote:

>
> My task is to enable a (remote) server to run VMs via qemu/KVM.
>
> The server is configured to set up its eth0 via openrc but this isn't
> enough to run the VMs network.
>
> I tried macvtap but something didn't work, either libvirt (yes, with
> USE-flag "macvtap") or something else (the kernel supports mavtap).
>
> So bridging.
>
> I'd like to keep the risk of losing connectivity as low as possible ... I
> can visit the place in a few weeks to iron out things but I would like to
> set up a bridge now without failure, just to get that VM running asap.
>
> Could anyone advise me in doing this?
>
> I have only ssh-access now ... its openrc-driven, and I might use a second
> IPv4-IP if that helps ...
>
> anyone?
>
> (editing the conf.d-files to remove eth0 and setup br0 is too scary right
> now. One mistake and the box is offline)
>
>
If you need the VMs outwardly visible, I can't think of a way to do it
without losing connection upon switching to the bridge (granted, I'm far
from an expert on bridging under linux). If you're fine with the VMs being
behind a NAT, and your kernel has the support for it, add the vm interfaces
to a bridge, enable net.ipv4.ip_forward and set up the NAT like any other
dual homed linux router... iptables-apply being your best friend for
testing changes without permanently losing access and/or having to reboot
to restore access.

-- 
Joshua M. Murphy

[-- Attachment #2: Type: text/html, Size: 1970 bytes --]

Re: [gentoo-user] low risk network bridge

[Stefan G. Weichinger]

On 06.05.2015 23:14, Poison BL. wrote:

> If you need the VMs outwardly visible, I can't think of a way to do it
> without losing connection upon switching to the bridge (granted, I'm far
> from an expert on bridging under linux). If you're fine with the VMs being
> behind a NAT, and your kernel has the support for it, add the vm interfaces
> to a bridge, enable net.ipv4.ip_forward and set up the NAT like any other
> dual homed linux router... iptables-apply being your best friend for
> testing changes without permanently losing access and/or having to reboot
> to restore access.

hmm maybe I have to drive there and just fix it on the local console.

macvtap would be more elegant, right? No need for a bridge.
I will research that asap ... today I have to solve more urgent problems ...

thx, S

Re: [gentoo-user] low risk network bridge

[R0b0t1]

# ip link
3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP>
5: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP>
6: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP>
7: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP>

Assign what was the host machine's IP to br0. The guests on tap0 and
tap1 should have IP addresses different from this, configured within
the guest.

# ip route
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.2

Now, the config that (mostly) generates the above:

config_tap0="null"
tuntap_tap0="tap"
tunctl_tap0="-u kvm"

config_tap1="null"
tuntap_tap1="tap"
tunctl_tap1="-u kvm"

config_enp2s0="null"
routes_enp2s0="null"

config_br0="192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255"
routes_br0="default via 192.168.1.1"
bridge_br0="enp2s0 tap0 tap1"
rc_net_br0_need="net.tap0 net.tap1 net.enp2s0"

The -u option allows users in the kvm group to manipulate the device,
if you want to bring it up and down on guest start and stop.

Unfortunately I don't think this produces VM interfaces that are
visible outside of the subnet. I made some live changes a while ago
(and need to figure out what they were - probably routing stuff). In
any case, you should be able to create the tap devices and bridge them
without losing connectivity. From there you can get the guests visible
from the outside.

Re: [gentoo-user] low risk network bridge

[Stefan G. Weichinger]

On 07.05.2015 13:21, R0b0t1 wrote:

> Unfortunately I don't think this produces VM interfaces that are
> visible outside of the subnet. I made some live changes a while ago
> (and need to figure out what they were - probably routing stuff). In
> any case, you should be able to create the tap devices and bridge them
> without losing connectivity. From there you can get the guests visible
> from the outside.

thanks!

but ... I got it working with macvtap today ;-)

To me this looks more elegant and efficient anyway ... I will read a bit
more about that when things calm down here.

In the current mode "VEPA" the host itself can't reach the VM  ... that
does not matter in that setup ... but it would matter for me if I set up
my local VMs that way (but I have a bridge here locally so that does not
matter)

busy days, much to learn ... ;-)

Thanks so far, Stefan