Re: macvtap with disconnected physical interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Il 2022-05-03 23:15 Gionatan Danti ha scritto:
I generally use plain bridge for my KVM setup. Specifically, when
using VLANs I setup the following:
eth -> eth.xx -> bridge -> vnet

This time, however, I need *both* a trunk-enabled VM (a virtual
firewall) and other segregated virtual machines. A "plain" bridge
setup would be something as:
eth -> bridge -> bridge.xx -> bridge -> vnet

Notice the two bridges, needed because bridge.xx is a VLAN interface
when no vnet can be directly attached. To avoid the double bridges, I
tried the following:
eth -> bridge -> bridge.xx -> macvtap

It seems to work very well but, during testing, I discovered that if
the interface under the macvtap one (in this case the bridge itself)
goes down, inter-guest networking is lost. As a side note, in the
specific scenario I described above, such issues can not really
happen: as a vnet interface is going to be always bound to the first
bridge, it will be *always* up due to the vnet interface itself being
always up (irrespective of the physical link status) and forcing the
bridge up.

However, working so well, I thought to change my classical bridge
setup with a macvtap based one even for simpler installation. In
short, going from:
eth -> bridge -> vnet
eth -> macvtap

But this very simple setup is going deny all guest traffic should the
physical interface become disconnected. A very crude solution would be
to issues "ip link set macvtap0 protodown off" when the physical link
goes down, but I wonder if a better solution exists.

That said, is replacing classical bridges with macvtap interfaces a
bad idea? Anything I should know before doing that?

Hi all,
any comment / suggestion on the steps described above? Does a simpler approach exists?


Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. -
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux