qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state
Date: Sat, 11 Jul 2009 00:14:24 +0100	[thread overview]
Message-ID: <20090710231424.GD30322@shareable.org> (raw)
In-Reply-To: <4A55F641.6000701@codemonkey.ws>

Anthony Liguori wrote:
> Paolo Bonzini wrote:
> >On 07/09/2009 03:45 PM, Anthony Liguori wrote:
> >>How does the disk become full during the final stage?  The guest isn't
> >>running.
> >
> >The host disk can become full and cause a "migrate exec" to fail.  Or 
> >for network migration migration, you could have the connection drop 
> >exactly during the final stage.  In this case, the VM would be 
> >unconditionally restarted.
> 
> Because migration failed.  Is that not the desired behavior?  It seems 
> like it is to me.
> 
> If I try to do a live migration, it should either succeed and my guest 
> experiences minimal downtime or it should fail and my guest should 
> experience minimal downtime.

What happens if the destination host sends "migration completed", and
then the connection drops before that message is delivered reliably to
the sending host?

The destination host will run the VM,
and the sending host will restart and run the VM too.

Two copies of the same VM running together doesn't sound healthy.

This is a classic handshaking problem and I'm not aware of any perfect
solution, only ways to ensure eventual recovery, and temporary
uncertainty errs on the side of caution.  In this case, caution would
be neither VM running but a notification to the system manager of this
rare condition, and the possibility to recover when the two hosts are
able to resume communication.  I don't know how to do better than that.

-- Jamie

  parent reply	other threads:[~2009-07-10 23:14 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 [this message]
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
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=20090710231424.GD30322@shareable.org \
    --to=jamie@shareable.org \
    --cc=anthony@codemonkey.ws \
    --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).