Re: [Qemu-devel] [PATCH 0/17 v3] Localhost migration with side channel for ram

[Lei Li <lilei@linux.vnet.ibm.com>]

On 11/25/2013 05:48 PM, Paolo Bonzini wrote:
> Il 25/11/2013 08:29, Lei Li ha scritto:
>>
>> In this case, if the migration would fail just because the misconfiguration
>> of device state on destination, in the meantime the outgoing migration has
>> no aware of this failure, I think it should add such handling (like synchronize
>> of the device state list in incoming side?) to the current migration protocol
>> as it is kind of missing... It can not just rely on the resume of source
>> guest for such failure... or maybe it should be handled in management
>> app to force the configuration right?
> It is already handled by libvirt, indeed.
>
> Basically, "-incoming" without "-S" is a broken option because of the
> missing handshake at the end of migration.  With "-S" something else
> (either a human or a program) can check that everything went well and
> choose whether to restart the source or the destination.

I see, thanks for your explanation.  :-)

BTW, do you think we should add such handling to the current migration
protocol?

>
>>> Postcopy would fix this (assuming the postcopy phase is reliable) by
>>> migrating device data before any page flipping occurs.
>> Are you suggesting that page flipping should be coupled with the postcopy
>> migration for live upgrade of QEMU as your comments in the previous
>> version?
> In order to make live upgrade reliable, it should.

The whole procedure for page flipping migration is straight forward, and
the cases of failure I listed are in theory, which never happened at least
since many times I have tested (except the case you raised above). But I
agree with you on coupling with postcopy migration to make it more reliable,
specially for the undetected problems.

For this, I am not quite sure I understand it correctly, seems the latest
update of post copy migration was sent on last Oct, would you please give
some insights on what else could I do for the coupling with postcopy migration?

If no, now page flipping is implemented as a migration capability, and it's
a good shape already as your comments in the previous version. Although it
still needs a little more time to get the numbers of the new vmsplice, I'd to
ask your opinion that do you consider it could be merged as an experimental
version for now?


>
> Paolo
>


-- 
Lei