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

Re: macvtap direct

On 5/13/20 12:52 AM, Subhendu Ghosh wrote:

Couple of questions around macvtap direct usage:

1) is the document here current?

Yes. 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>

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]