[Top][All Lists]

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

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

From: Lei Li
Subject: Re: [Qemu-devel] [PATCH 0/17 v3] Localhost migration with side channel for ram
Date: Tue, 26 Nov 2013 19:07:34 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

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

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
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?



reply via email to

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