On Thu, May 14, 2020 at 1:32 PM Laine Stump <laine@xxxxxxxxxx> 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
External bridge/switch is only needed for VEPA mode with hairpin.
Perhaps the original development of macvtap to support VEPA influenced the early docs and was never reviewed after bridge mode matured?
>
> 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().
