qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Orit Wasserman <owasserm@redhat.com>
To: junqing.wang@cs2c.com.cn
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 0/4] Curling: KVM Fault Tolerance
Date: Thu, 12 Sep 2013 10:37:57 +0300	[thread overview]
Message-ID: <52316F55.7090307@redhat.com> (raw)
In-Reply-To: <4bf58665.2cac.1410aba5e17.Coremail.junqing.wang@cs2c.com.cn>

On 09/11/2013 04:54 AM, junqing.wang@cs2c.com.cn wrote:
> Hi,
> 
>>The first is that if the VM failure happen in the middle on the live migration  >the backup VM state will be inconsistent which means you can't failover to it.
> 
> Yes, I have concerned about this problem. That is why we need a prefetch buffer.
> 

You are right I missed that.

>>Solving it is not simple as you need some transaction mechanism that will >change the backup VM state only when the transaction completes (the live migration completes). >Kemari has something like that. >
> 
> The backup VM state will be loaded only when the one whole migration data is prefetched. Otherwise, VM state will not be loaded. So the backup VM is ensured to have a consistent state like a checkpoint.
> However, how close this checkpoint to the point of the VM failure depends on the workload and bandwidth.
> 

At the moment in your implementation the prefetch buffer can be very large (several copies of guest memory size) 
are you planning to address this issue?

>>The second is that sadly live migration doesn't always converge this means  >that the backup VM won't have a consist state to failover to. >You need to detect such a case and throttle down the guest to force convergence.
> 
> Yes, that's a problem. AFAK, qemu already have an auto convergence feature.

How about activating it when you do fault tolerance automatically?

> From another perspective,  if many migrations could not converge, maybe the workload is high and the bandwidth is low,  and it is not recommended to use FT in general.
> 

I agree but we need some way to notify the user of such problem.

Regards,
Orit
> 
> 

  reply	other threads:[~2013-09-12  7:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10  3:43 [Qemu-devel] [PATCH RFC 0/4] Curling: KVM Fault Tolerance Jules Wang
2013-09-10  3:43 ` [Qemu-devel] [PATCH RFC 1/4] Curling: add doc Jules Wang
2013-09-10  3:43 ` [Qemu-devel] [PATCH RFC 2/4] Curling: cmdline interface Jules Wang
2013-09-10 13:57   ` Juan Quintela
2013-09-10 13:03     ` Paolo Bonzini
2013-09-10 16:37       ` Juan Quintela
2013-09-10 14:38         ` Paolo Bonzini
2013-09-10 15:21           ` Juan Quintela
2013-09-10 15:22           ` Juan Quintela
2013-09-11  2:51     ` junqing.wang
2013-09-10  3:43 ` [Qemu-devel] [PATCH RFC 3/4] Curling: the sender Jules Wang
2013-09-10 14:05   ` Juan Quintela
2013-09-11  7:31     ` junqing.wang
2013-09-10  3:43 ` [Qemu-devel] [PATCH RFC 4/4] Curling: the receiver Jules Wang
2013-09-10 14:19   ` Juan Quintela
2013-09-11  8:25     ` junqing.wang
2013-09-10 12:27 ` [Qemu-devel] [PATCH RFC 0/4] Curling: KVM Fault Tolerance Orit Wasserman
2013-09-11  1:54   ` junqing.wang
2013-09-12  7:37     ` Orit Wasserman [this message]
2013-09-12  8:17       ` junqing.wang

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=52316F55.7090307@redhat.com \
    --to=owasserm@redhat.com \
    --cc=junqing.wang@cs2c.com.cn \
    --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).