On Sun, 10 Mar 2019 11:16:33 +0100
Markus Armbruster <arm...@redhat.com> wrote:
> Daniel P. Berrangé <berra...@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é <berra...@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 <mpriv...@redhat.com>
> >> > > AuthorDate: Thu Dec 18 12:36:48 2014 +0100
> >> > > Commit: Michal Privoznik <mpriv...@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.
Isn't it typically a job of downstream to ship a bundle that works
together and it is rather limited set.
e.g
System 1 libvirt 0 QEMU 0 (machine 0.1 (latest)) could be migrated to 2 ways
to
System 2 libvirt 1 QEMU 1 (machine 0.1 (still the same old machine))
while installing QEMU 1 on System 1 might work (if it doesn't break due to
dependencies)
and even be able to start machine 1.0, wouldn't it really fall in unsupported
category?
> 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.
On top of that libvirt should be willing to adapt to the new way for above
combination.
I'm experimenting with making 'mem' migration compatible with 'memdev'
(I have a working hack currently) to get a feeling of a toll it would
take on QEMU, so far outlook isn't good. It just adds more compat code
and new CLI options to deal with it (it just increases amount of
maintenance nightmare for indefinite period of time). And everyone would
hate adding such new CLI options which as it turns out we aren't able to
deprecate and remove in practice.
We really need to figure out how to introduce breaking change on management
(CLI) side* in QEMU and make it digestible for libvirt and others.
(* at least for new machine types).
