On 5/18/20 10:51 PM, Subhendu Ghosh wrote:
On Thu, May 14, 2020 at 1:32 PM Laine Stump <laine@xxxxxxxxxx
<mailto: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
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().
