macvtap direct

[Laine Stump]

On 5/18/20 10:51 PM, Subhendu Ghosh wrote:
> 
> 
> On Thu, May 14, 2020 at 1:32 PM Laine Stump <laine at redhat.com 
> <mailto:laine at redhat.com>> wrote:
> 
>     On 5/13/20 12:52 AM, Subhendu Ghosh wrote:
>      > Hi
>      >
>      > Couple of questions around macvtap direct usage:
>      >
>      > 1) is the document here current?
>      > https://libvirt.org/formatnetwork.html#examplesDirect
> 
>     Yes. None of that has changed in any major way in many years.
> 
> 
> kernelNewbies documents mactap bridge as VMs can host can all talk to 
> each other without an external bridge


Correct. The VMs can talk to each other, but they can't talk to the host.


> External bridge/switch is only needed for VEPA mode with hairpin.

VEPA is a special IBM thing that requires a particular kind of switch. 
bridge mode macvtap still doesn't allow direct communication between 
host and guest - it requires a switch that hairpins traffic, or for the 
host to have a separate macvlan interface that is attached to the 
ethernet device (so that it is a peer to the guests' macvtap devices, 
and they can communicate with it).

> 
> https://virt.kernelnewbies.org/MacVTap
> 
> Perhaps the original development of macvtap to support VEPA influenced 
> the early docs and was never reviewed after bridge mode matured?

No.

If you are able to communicate between your host and guests that are 
connected only via a macvtap bridge mode connection, then either your 
switch is hairpinning the traffic, or you have a separate macvlan 
interface for the host that is attached to the ethernet. There was no 
"change in design after early docs that was never reviewed" - the 
design/implementation of macvtap is as it is documented.

(Just because your claim made me doubt myself, I checked again on a 
Fedora 32 host and verified that it still works as it always has).


> 
> 
> 
>      >
>      > I have been able to get host to guest network traffic without any
>      > special configuration or switch since Fedora 28 when I first started
>      > using it. Using <forward mode=vepa> requires switch port
>     mirroring, but
>      > just using <forward mode=bridge> doesn't.
> 
> 
>     If that is the case, then either your guest and host have a secondary
>     network connection, or your switch is mirroring traffic and you just
>     didn't know about it. The inability to do direct host<->guest
>     communication is inherent in the design of macvtap interfaces.
> 
> 
>      >
>      > 2) do any of the language libraries make assumptions that libvirt
>      > networks must have a <bridge name=xx> attribute? Foreman's Ruby
>      > interface to libvirt errors out with attempting to build a VM on
>     a KVM
>      > host with a network defined with <forward mode=bridge>
>      > https://projects.theforeman.org/issues/25890
> 
>     The 2nd line in the log attached to that issue report says this:
> 
>       >Call to virNetworkGetBridgeName failed: internal error: network
>     'macvtap-net' does not have a bridge name.
> 
>     So, your application (or whatever this "Foreman's Ruby interface to
>     libvirt" is) has called virNetworkGetBridgeName() (whatever it's called
>     in the Ruby bindings), and since you have a macvtap network, which has
>     no bridge device, libvirt sent back an error. You need to find whatever
>     in your code is calling virNetworkGetBridgeName().
>