macvtap with disconnected physical interface

[Gionatan Danti]

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 at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8