qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries
Date: Tue, 23 Feb 2016 09:31:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Greg Kurz <address@hidden> wrote:
> On Fri, 19 Feb 2016 11:11:47 +1100
> David Gibson <address@hidden> wrote:
>
>> On Thu, Feb 18, 2016 at 12:32:11PM +0100, Greg Kurz wrote:
>> > QEMU 2.4 broke the migration of old pseries machine with the addition
>> > of configuration sections, which are sent unconditionally.
>> > 
>> > We assume that QEMU 2.3 is more deployed than any newer release (based on
>> > the versions currently shipped by most distros). This v3 series hence
>> > reverses the logic from v2: it now fully fixes migration of old pseries
>> > from/to QEMU 2.3 and provides a manual workaround for the QEMU 
>> > 2.4/2.4.1/2.5
>> > case.
>> > 
>> > With this series, I could migrate the same pseries-2.3 instance in a full
>> > 2.3->2.6->2.5->2.6->2.4->2.6->2.3 cycle.  
>> 
>> Sorry, I've lost track slightly here.  Does this series apply on top
>> of, or instead of your earlier series that peeks for the config
>> section?
>> 
>
> This v3 series applies instead of the v2 that peeks for the config section.
>
> It was suggested by Laurent during review, and motivated by your decision
> to favor fixing 2.3 over 2.4.
>
> As shown in Laurent's detailed test report, migration from/to 2.3.x now works
> out of the box and 2.4.x/2.5 requires qom-set.
>
> I was also feeling a bit uncomfortable with all these machine properties to
> disable the configuration section, which was explicitly coded to be 
> non-optional
> according to the changelog of commit 61964c23. The logic inversion in v3 seem
> to be friendlier with the configuration section design.
>
> Juan, could you share your thoughts ?

As said previously, we don't have any better fix.  We could try to make
the "enforce" thing only for some machine types, but I guess that it
would make the mess even bigger :-(

And on an unrelated topic, I guess we need to "agree" in a way to add
new features to migration for all machine types.  Right now we have:
- two x86 boards
- now s390
- and now ppc
- and I guess arm is on the way

So, I guess we would need something like of what we have on
hw/i386/pc_piix.c


static void pc_compat_2_3(MachineState *machine)
{
    PCMachineState *pcms = PC_MACHINE(machine);
    savevm_skip_section_footers();
    if (kvm_enabled()) {
        pcms->smm = ON_OFF_AUTO_OFF;
    }
    global_state_set_optional();
    savevm_skip_configuration();
}


Really, we need something like this

static void migration_compat_2_3(MachineState *machine)
{
    savevm_skip_section_footers();
    global_state_set_optional();
    savevm_skip_configuration();
}

to be included in every machine that cares about migration.  Is there
ane easy way/place where to do this globaly?

Later, Juan.



reply via email to

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