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@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
