On Mon, Jul 07, 2025 at 09:19:56 +0100, Daniel P. Berrangé wrote:
On Mon, Jul 07, 2025 at 09:03:06AM +0200, Peter Krempa via Devel
wrote:
> From: Peter Krempa <pkrempa(a)redhat.com>
>
> The example allows packets sent by qemu after migration with broken
> protocol ID. The proper self announce is handled via
> 'qemu-announce-self-rarp'.
>
> The qemu bug was addressed by f8778a7785d530515b0db39 (released as
> v0.13.0). As we no longer support such old qemus, and allowing broken
> packets makes no sense remove the filter, and adjust the existing ones
> to refer to the proper name.
>
> Closes:
https://gitlab.com/libvirt/libvirt/-/issues/792
> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> diff --git a/src/nwfilter/xml/qemu-announce-self.xml
b/src/nwfilter/xml/qemu-announce-self.xml
> deleted file mode 100644
> index 352db500de..0000000000
> --- a/src/nwfilter/xml/qemu-announce-self.xml
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -<filter name='qemu-announce-self' chain='root'>
> - <!-- as of 4/26/2010 qemu sends out a bogus packet with
> - wrong rarp protocol ID -->
> - <!-- accept what is being sent now -->
> - <rule action='accept' direction='out'>
> - <mac protocolid='0x835'/>
> - </rule>
> -
> - <!-- accept if it was changed to rarp -->
> - <filterref filter='qemu-announce-self-rarp'/>
> - <filterref filter='no-other-rarp-traffic'/>
> -
> -</filter>
Deleting this filter entirely risks upgrade problems for apps if
they're referencing, which is quite possible given it was one of
our standard filters for decades.
Hmm, yeah, while I did think about upgrades themselves where this should
work as we *copy* the files from 'datadir' to 'sysconfdir' in %post,
thus the old file will be left around for cases where this was
installed, if someone actually used this in their filter definition we'd
break them on new instalation.
Perhaps keep it, but cut down rules such that it acts exactly as
an alias of qemu-announce-self-rarp.
Yeah, this should be straightforward if we want to keep user-defined
filter rules depending on our examples working.
I can find arguments for etiher behaviour, but I'm leaning towards
making this just include the '-rarp' version as it was the intended way.