Re: [libvirt] [Qemu-devel] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option
Daniel P. Berrangé <berrange(a)redhat.com> writes:
On Wed, Mar 06, 2019 at 08:03:48PM +0100, Igor Mammedov wrote:
> On Mon, 4 Mar 2019 16:35:16 +0000
> Daniel P. Berrangé <berrange(a)redhat.com> wrote:
>
> > On Mon, Mar 04, 2019 at 05:20:13PM +0100, Michal Privoznik wrote:
> > > We couldn't have done that. How we would migrate from older qemu?
> > >
> > > Anyway, now that I look into this (esp. git log) I came accross:
> > >
> > > commit f309db1f4d51009bad0d32e12efc75530b66836b
> > > Author: Michal Privoznik <mprivozn(a)redhat.com>
> > > AuthorDate: Thu Dec 18 12:36:48 2014 +0100
> > > Commit: Michal Privoznik <mprivozn(a)redhat.com>
> > > CommitDate: Fri Dec 19 07:44:44 2014 +0100
> > >
> > > qemu: Create memory-backend-{ram,file} iff needed
> > >
> > > Or this 7832fac84741d65e851dbdbfaf474785cbfdcf3c. We did try to generated
> > > newer cmd line but then for various reasong (e.g. avoiding triggering a
qemu
> > > bug) we turned it off and make libvirt default to older (now deprecated)
cmd
> > > line.
> > >
> > > Frankly, I don't know how to proceed. Unless qemu is fixed to allow
> > > migration from deprecated to new cmd line (unlikely, if not impossible,
> > > right?) then I guess the only approach we can have is that:
> > >
> > > 1) whenever so called cold booting a new machine (fresh, brand new start
of
> > > a new domain) libvirt would default to modern cmd line,
> > >
> > > 2) on migration, libvirt would record in the migration stream (or status
XML
> > > or wherever) that modern cmd line was generated and thus it'll make
the
> > > destination generate modern cmd line too.
> > >
> > > This solution still suffers a couple of problems:
> > > a) migration to older libvirt will fail as older libvirt won't
recognize the
> > > flag set in 2) and therefore would default to deprecated cmd line
> > > b) migrating from one host to another won't modernize the cmd line
> > >
> > > But I guess we have to draw a line somewhere (if we are not willing to
write
> > > those migration patches).
> >
> > Yeah supporting backwards migration is a non-optional requirement from at
> > least one of the mgmt apps using libvirt, so breaking the new to old case
> > is something we always aim to avoid.
> Aiming for support of
> "new QEMU + new machine type" => "old QEMU + non-existing machine
type"
> seems a bit difficult.
That's not the scenario that's the problem. The problem is
new QEMU + new machine type + new libvirt -> new QEMU + new machine type + old
libvirt
Previously released versions of libvirt will happily use any new machine
type that QEMU introduces. So we can't make new libvirt use a different
options, only for new machine types, as old libvirt supports those machine
types too.
Avoiding tight coupling between QEMU und libvirt versions makes sense,
because having to upgrade stuff in lock-step is such a pain.
Does not imply we must support arbitrary combinations of QEMU and
libvirt versions.
Unless upstream libvirt's test matrix covers all versions of libvirt
against all released versions of QEMU, "previously released versions of
libvirt will continue to work with new QEMU" is largely an empty promise
anyway. The real promise is more like "we won't break it intentionally;
good luck".
Mind, I'm not criticizing that real promise. I'm criticizing cutting
yourself off from large areas of the solution space so you can continue
to pretend to yourself you actually deliver on the empty promise.
Now, if you limited what you promise to something more realistic,
ideally to something you actually test, we could talk about deprecation
schedules constructively.
For instance, if you promised
QEMU as of time T + its latest machine type + libvirt as of time T
-> QEMU as of time T + its latest machine type + libvirt as of time T - d
will work for a certain value of d, then once all released versions of
libvirt since T - d support a new way of doing things, flipping to that
new way becomes a whole lot easier.