All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kunkun Jiang <jiangkunkun@huawei.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: David Edmondson <dme@dme.org>,
	Juan Quintela <quintela@redhat.com>,
	"open list:All patches CC here" <qemu-devel@nongnu.org>,
	Peter Xu <peterx@redhat.com>, Zenghui Yu <yuzenghui@huawei.com>,
	wanghaibin.wang@huawei.com, Keqian Zhu <zhukeqian1@huawei.com>
Subject: Re: [question] The source cannot recover, if the destination fails in the last round of live migration
Date: Fri, 7 May 2021 17:46:44 +0800	[thread overview]
Message-ID: <dd990878-fb0f-5bfc-f390-d6807b158372@huawei.com> (raw)
In-Reply-To: <YJPpr0z+sV3lQMxZ@work-vm>

Hi Dave,

On 2021/5/6 21:05, Dr. David Alan Gilbert wrote:
> * Kunkun Jiang (jiangkunkun@huawei.com) wrote:
>> Hi all,
> Hi,
>
>> Recently I am learning about the part of live migration.
>> I have a question about the last round.
>>
>> When the pending_size is less than the threshold, it will enter
>> the last round and call migration_completion(). It will stop the
>> source and sent the remaining dirty pages and devices' status
>> information to the destination. The destination will load these
>> information and start the VM.
>>
>> If there is an error at the destination at this time, it will exit
>> directly, and the source will not be able to detect the error
>> and recover. Because the source will not call
>> migration_detect_error().
>>
>> Is my understanding correct?
>> Should the source wait the result of the last round of destination ?
> Try setting the 'return-path' migration capability on both the source
> and destination;  I think it's that option will cause the destination to
> send an OK/error at the end and the source to wait for it.
Thank you for your reply!
The 'return-path' migration capability solved my question. 😁

But why not set it as the default? In my opinion, it is a basic ability
of live migration. We need it to judge whether the last round of the
destination is successful in the way of 'precopy'.

Looking forward to your reply.

Thanks,
Kunkun Jiang
> Dave
>
>> Thanks,
>> Kunkun Jiang
>>
>>



  reply	other threads:[~2021-05-07  9:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 13:02 [question] The source cannot recover, if the destination fails in the last round of live migration Kunkun Jiang
2021-05-06 13:05 ` Dr. David Alan Gilbert
2021-05-07  9:46   ` Kunkun Jiang [this message]
2021-05-07 14:57     ` Peter Xu
2021-05-10  8:46       ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd990878-fb0f-5bfc-f390-d6807b158372@huawei.com \
    --to=jiangkunkun@huawei.com \
    --cc=dgilbert@redhat.com \
    --cc=dme@dme.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.