[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: macvtap direct

On 5/18/20 10:51 PM, Subhendu Ghosh wrote:

On Thu, May 14, 2020 at 1:32 PM Laine Stump <laine redhat com <mailto:laine 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).


Perhaps the original development of macvtap to support VEPA influenced the early docs and was never reviewed after bridge mode matured?


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().

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]