Re: macvtap with disconnected physical interface

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


Il 2022-05-03 14:58 Laine Stump ha scritto:
I can't say that I've ever tried this, since my only reason for using
macvtap is to provide the guests with direct connectivity to the
physical network, and unplugging the physdev negates that. The
behavior you describe doesn't surprise me all that much though, since
the physical device in the case of a host bridge isn't an integral
part of the bridge (it's just one more device attached to a port),
while the physical device and macvlan bridge a much more closely

Yeah, it sound very plausible.

I'm Cc'ing Michael Tsirkin to see if he has more authoritative
information on whether or not the macvtaps connected to a macvlan
bridge can communicate amongst themselves when the physdev is


In the meantime, is there a reason you don't want to just use a
standard host bridge that's not connected to any physdev? The one
thing I can think of is that you might not want to allow communication
between the host and guests, but as long as the bridge itself isn't
given an IP address, that won't be possible (at least at the level of

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?

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