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
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
# 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
On Wed, May 6, 2015 at 3:59 PM, Stefan G. Weichinger li...@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
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
5 matches
Mail list logo