[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version
Date: Wed, 28 May 2014 13:44:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Il 28/05/2014 13:20, Dr. David Alan Gilbert (git) ha scritto:
From: "Dr. David Alan Gilbert" <address@hidden>

This patch set provides an optional parameter to 'migrate' giving
the destination QEMU version, it's intended for those having to maintain
compatibility between minor versions (including downstream versions) and
also for those who need to think about backwards migration.

There aren't any uses of the migration version in this patch set, however
uses I can think of include:
    a) Generating an old format for a particular device when sent to a
       particular version
    b) Fudging a register value for a particular version
    c) Fudging around more general problems (e.g. the 1.6.x short PCI naming)


If we had a way for the 'save' side of migrate to fail cleanly with an error
then we could also do some pre-migrate checks and flag things that just aren't
going to work (e.g. noticing that a new feature is enabled on a device that
the old one doesn't have).

I don't think this is necessary; not yet at least.

In quite a few years of experience with backwards migration between RHEL6 releases, we never found a deal breaker. We only found one for 1.5->0.12 migration, and what broke the deal was not QEMU changes but firmware incompatibility (RHEL7 SeaBIOS not working on RHEL6).

Of the above three cases, (a) and (b) can be handled by machine types.

(c) should have been caught by testing, and is not entirely solved by this approach. It would fix 2.0->1.6 migration, but not 1.6->2.0 migration with -M pc-1.5. In other words, it would not fix the case that we care about in upstream.

Version numbers open a huge compatibility can of worms (what is a version number?) and don't solve the fundamental problem of migration receiving insufficient testing with upstream QEMU versions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]