From: Paolo Bonzini <pbonzini@redhat.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>,
Eric Blake <eblake@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "quintela@redhat.com" <quintela@redhat.com>,
Zengjunliang <zengjunliang@huawei.com>,
"libvir-list@redhat.com" <libvir-list@redhat.com>,
Yanqiangjun <yanqiangjun@huawei.com>,
"Zhaoyanbin (A)" <lefty.zhao@huawei.com>,
"owasserm@redhat.com" <owasserm@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] migration: Fix possible bug for migrate cancel
Date: Fri, 28 Mar 2014 10:28:45 +0100 [thread overview]
Message-ID: <533540CD.7040801@redhat.com> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF19020815DBCE6@SZXEMA503-MBS.china.huawei.com>
Il 28/03/2014 10:18, Gonglei (Arei) ha scritto:
>> > > Can you please give more details at how you are triggering the problem
>> > > with libvirt? I think Paolo is probably right - the bug is more likely
>> > > to be in libvirt not expecting the race and not recovering correctly
>> > > when the race occurs, than it is to be in changing qemu's state algorithm.
>> > >
>> When the migration progress reaches 100%, and the migration status becomes
>> MIG_STATE_COMPLETED in Qemu.
>> It will take some time which from MIG_STATE_COMPLETED to the migration
>> thread resources are recovered.
>> If we cancel the migration at this moment, the migrate_fd_cancel function will
>> break directly without reporting
>> error code. Then, libvirt considers the cancle operation a success, contrary
>> facts.
There is no error, once migration is completed you can still shutdown on
the destination and continue on the source. Libvirt should either:
1) poll with "query-migrate" after migrate_cancel, and report an error
there if it's the desired semantics;
2) toggle a "cancelled" flag before asking QEMU to cancel migration,
check it in the migration functions after "query-migrate" reported
completion; if it is true, do not resume on the destination.
Another reason for doing it in libvirt is that the serialization between
cancellation and completion of migration ultimately is controlled by
libvirt's lock. Doing this in QEMU makes it harder to reason about
concurrency.
Paolo
next prev parent reply other threads:[~2014-03-28 9:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-24 13:04 [Qemu-devel] [PATCH] migration: Fix possible bug for migrate cancel arei.gonglei
2014-03-24 14:14 ` Eric Blake
2014-03-24 15:47 ` Paolo Bonzini
2014-03-24 16:00 ` Eric Blake
2014-03-25 11:15 ` Gonglei (Arei)
2014-03-28 9:18 ` Gonglei (Arei)
2014-03-28 9:28 ` Paolo Bonzini [this message]
2014-03-28 11:30 ` Dr. David Alan Gilbert
2014-03-28 12:16 ` Paolo Bonzini
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=533540CD.7040801@redhat.com \
--to=pbonzini@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=eblake@redhat.com \
--cc=lefty.zhao@huawei.com \
--cc=libvir-list@redhat.com \
--cc=owasserm@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yanqiangjun@huawei.com \
--cc=zengjunliang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).