Bug 1843270

Currently some scenarios using Multicast does not work properly.

In a customer ticket, OSPF (the routing protocol) inside a VM is broken because the VM does not receive Multicast frames "224.0.0.5/01:00:5E:00:00:05" as they are dropped by the macvtap device (VM-FEX) on the host.

We found 2 ways to make the macvtap pass the frames to the VM:
* enable allmulticast on the macvtap
* enable TrustGuestRxFilters on the interface XML.

The first option makes all eth mac multicast addresses reach the VM, so it is not ideal. The second option, AFAICS, makes the multicast filters configured by the VM OS on the virtio-net interface propagate to the macvtap interface, so specific addresses/ranges are not dropped by it.

https://libvirt.org/formatdomain.html#elementsNICS
~~~
the interface element property trustGuestRxFilters provides the capability for the host to detect and trust reports from the guest regarding changes to the interface mac address and receive filters by setting the attribute to yes. The default setting for the attribute is no for security reasons and support depends on the guest network device model as well as the type of connection on the host - currently it is only supported for the virtio device model and for macvtap connections on the host.
~~~

I wrote a quick VDSM hook for testing, and the customer confirmed that with trustGuestRxFilters='yes' VM now receives the multicast frames, so OSPF works.
~~~
doc = hooking.read_domxml()
for interface in doc.getElementsByTagName('interface'):
    interface.setAttribute('trustGuestRxFilters', 'yes')
hooking.write_domxml(doc)
~~~

While a supported VDSM hook may be enough, I think this ideally would be set by the engine and configurable on the vNIC profile (perhaps add it when network filters are disabled?)