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 associated.
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 disconnected.
Thanks.
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 IP).
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 to: 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? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8