Hi Couple of questions around macvtap direct usage: 1) is the document here current? https://libvirt.org/formatnetwork.html#examplesDirect 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. 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 thanks Subhendu
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#examplesDirectYes. None of that has changed in any major way in many years.> > 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/25890The 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().
On Thu, May 14, 2020 at 1:32 PM Laine Stump <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 External bridge/switch is only needed for VEPA mode with hairpin. 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?> > > > 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(). > >