[libvirt] [PATCH 6/8] virQEMUCapsSetFromNodes: Skip setting deprecated flags

[Erik Skultety]

On Thu, Mar 07, 2019 at 01:23:14PM +0100, Michal Privoznik wrote:
> On 3/7/19 1:07 PM, Daniel P. Berrangé wrote:
> > On Thu, Mar 07, 2019 at 12:52:46PM +0100, Erik Skultety wrote:
> > > > However, looking at the bigger picture is this a safe thing to do? I mean,
> > > > imagine the following scenario:
> > > >
> > > > 1) say there is capability X that affects certain part of cmd line. And
> > > > assume that those two possibilities are incompatible. If cmd line is
> > > > generated one way then migration to a qemu which has cmd line generated the
> > > > other way fails.
> > > >
> > > > 2) in release R we deprecate X and thus do not format it in <capabilities/>
> > > > in status XML.
> > > >
> > > > 3) user starts a domain D.
> > > >
> > > > 4) user saves D into a file
> > > >
> > > > 5) sysadmin downgrades libvirt to R-1
> > >
> > > Do we even support downgrade this way? I know we migrate to older version but
> > > isn't that different?
>
> Okay, forget about save+restore. Let's just keep the domain D running and
> then downgrade libvirt. Now, instead of X affecting cmd line let it affect
> how we talk to qemu on monitor. Since R assumed X always being there then X
> wouldn't be recorded in status XML. Later when R-1 daemon is starting and
> parsing the status XML it won't find X and thus might make wrong decissions.
> For instance, if X would be some capability that affects the way we generate
> PCI addresses for guest devices, then this would really harm the user.
>
> Worse, let just start the domain with R-1, then upgrade to R to test it,
> call an API over D (at which point the status XML is regenerated, now
> without X stored in it), find that it's not working so roll back to R-1 and
> puff. The capability is gone.

I understand the X_ flags as something we implicitly expect from QEMU, IOW we
bump the minimal version of QEMU we expect (with all the supported distros in
mind) and so we mark a bunch of capabilities with X, if we drop them, how is
what you're describing an issue since the capability is implicitly assumed to
be supported by given version of QEMU regardless of libvirt version?
Maybe I misunderstood your example, but I don't think we can ever mark a
capability as X if that is still not an integral part of that QEMU version.
Therefore, it should not affect the way we construct the cmdline and how we
talk to the monitor, right?

Erik