On Mon, Jul 07, 2025 at 12:16:07PM +0200, Peter Krempa wrote:
> 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.
In data center / cloud deployments I think "new provisioned host" is a
relatively common thing, and it might be surprising for admins to find
the new hosts are incomplete vs old hosts.
> > 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.
>
So basically nothing more than:
<filter name='qemu-announce-self' chain='root'>
<filterref filter='qemu-announce-self-rarp'/>
</filter>
...unless some future QEMU needs to announce a packet that is not rarp
based
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
