From: Anthony Liguori <anthony@codemonkey.ws>
To: Gleb Natapov <gleb@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Avi Kivity <avi@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state
Date: Mon, 13 Jul 2009 09:52:44 -0500 [thread overview]
Message-ID: <4A5B4A3C.1070903@codemonkey.ws> (raw)
In-Reply-To: <20090713053139.GD28046@redhat.com>
Gleb Natapov wrote:
> With unreliable socket it doesn't matter what write() returns data may
> or may not reach the destination regardless, with reliable sockets
> write() succeeds only after data was acked by the receiver, but it still
> doesn't mean that data will be read from destination socket.
>
You are correct and we handle both of these cases appropriately. In the
event that we think we completed a migration successfully and we really
didn't because of a lost network connection, the result is both the
source and destination are stopped. A third party can resume the source
and continue along happily.
The case being debated is whether write() can ever actually complete and
yet still return an error. In this case, since we automatically resume
the source on error, the result would be two copies of the VM running.
I haven't seen any evidence that this case could actually happen other
than theoretic speculation. I just at the migration code and it's not a
simple change to try and be conservative wrt this case because of the
way we do buffering.
Regards,
Anthony Liguori
> --
> Gleb.
>
next prev parent reply other threads:[~2009-07-13 14:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-09 11:47 [Qemu-devel] [PATCH 0/3] add "core dump"-like capability Paolo Bonzini
2009-07-09 11:47 ` [Qemu-devel] [PATCH 1/3] move state and mon_resume to struct MigrationState Paolo Bonzini
2009-07-09 11:47 ` [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state Paolo Bonzini
2009-07-09 13:45 ` Anthony Liguori
2009-07-09 13:48 ` Paolo Bonzini
2009-07-09 13:53 ` Anthony Liguori
2009-07-09 13:58 ` Paolo Bonzini
2009-07-09 14:41 ` Anthony Liguori
2009-07-10 23:14 ` Jamie Lokier
2009-07-11 0:04 ` malc
2009-07-11 0:42 ` Jamie Lokier
2009-07-11 0:55 ` Anthony Liguori
2009-07-11 0:58 ` Anthony Liguori
2009-07-11 1:42 ` Jamie Lokier
2009-07-12 3:31 ` Anthony Liguori
2009-07-12 14:22 ` Avi Kivity
2009-07-12 19:10 ` Anthony Liguori
2009-07-12 19:30 ` Avi Kivity
2009-07-13 5:31 ` Gleb Natapov
2009-07-13 8:05 ` Gleb Natapov
2009-07-13 14:52 ` Anthony Liguori [this message]
2009-07-14 8:48 ` Dor Laor
2009-07-14 14:41 ` Paolo Bonzini
2009-07-09 11:47 ` [Qemu-devel] [PATCH 3/3] add live dumping capability Paolo Bonzini
2009-07-09 13:49 ` Anthony Liguori
2009-07-09 14:06 ` Paolo Bonzini
2009-07-09 14:43 ` Anthony Liguori
2009-07-10 8:32 ` Paolo Bonzini
2009-07-10 12:51 ` Anthony Liguori
2009-07-09 13:42 ` [Qemu-devel] [PATCH 0/3] add "core dump"-like capability Anthony Liguori
2009-07-09 13:46 ` Paolo Bonzini
2009-07-09 13:51 ` Anthony Liguori
2009-07-09 14:46 ` Gerd Hoffmann
2009-07-09 16:20 ` 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=4A5B4A3C.1070903@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).