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 <pkre...@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 <pkre...@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.
