qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/4] configure: Add --enable-migration-from-qemu


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/4] configure: Add --enable-migration-from-qemu-kvm
Date: Thu, 28 Feb 2013 12:21:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

Il 21/02/2013 08:44, Paolo Bonzini ha scritto:
> Il 20/02/2013 22:03, Anthony Liguori ha scritto:
>> Paolo Bonzini <address@hidden> writes:
>>
>>> Il 20/02/2013 21:26, Anthony Liguori ha scritto:
>>>> Cole Robinson <address@hidden> writes:
>>>>
>>>>> This switch will turn on all the migration compat bits needed to
>>>>> perform migration from qemu-kvm to qemu. It's just a stub for now.
>>>>>
>>>>> This compat will break incoming migration from qemu < 1.3, but for
>>>>> distros where qemu-kvm was the only shipped package for years it's
>>>>> not a big loss (and I don't know any way to avoid it).
>>>>>
>>>>> Signed-off-by: Cole Robinson <address@hidden>
>>>>
>>>> This can't be a build time option.  It's ugly and just reintroduces a fork.
>>>
>>> It is not a fork; it does not change the migration format of QEMU
>>> itself, only the parsing of old VMState versions.  The importance of the
>>> fork will dwindle over time, as the distros EOL the releases that used
>>> qemu-kvm.
>>
>> Once a distro enables CONFIG_QEMU_KVM, it must keep it enabled forever.
>> So the distros will contineut o do CONFIG_QEMU_KVM whereas upstream does
>> not set it.  It's a fork all within the same tree.
> 
> They will set it for a while.  For example, F18 is the last Fedora
> release that had qemu-kvm < 1.3.0.  As soon as F18 goes end-of-life
> (which is with F21), Fedora will not need to set the configure option
> anymore.
> 
> Of course other distros will keep it for years rather than months, but
> the idea is the same.
> 
>> What about having something processed by readconfig that wasn't disabled
>> by -nodefaults?  Then we could make it a runtime option, but that's
>> configurable globally.  Then the distros can choose the default value in
>> the config file.
>>
>> At least then, we can write unit tests with the option at run time,
>> don't need to sprinkle #ifdefs everywhere, etc.
> 
> That would make sense, but it shouldn't block this patch.  What would
> happen otherwise is that distros (who care about migration
> compatibility) will just patch their code without even the #ifdefs.
> It's already happening, these patches are in F18.

Ping, where do we stand here?  Shall we discuss it next Tuesday?

Paolo




reply via email to

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