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

On Mon, 4 Mar 2019 16:35:16 +0000 Daniel P. Berrangé <berrange(a)redhat.com&gt; 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&gt; > > AuthorDate: Thu Dec 18 12:36:48 2014 +0100 > > Commit: Michal Privoznik <mprivozn(a)redhat.com&gt; > > 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.