[libvirt] [Qemu-devel] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option

[Daniel P. Berrangé]

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 at 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 at redhat.com>
> > > AuthorDate: Thu Dec 18 12:36:48 2014 +0100
> > > Commit:     Michal Privoznik <mprivozn at 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.

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 :|