All of lore.kernel.org
 help / color / mirror / Atom feed
From: g.danti@assyoma.it
To: Brian Jackson <iggy@theiggy.com>
Cc: <kvm@vger.kernel.org>
Subject: Re: KVM in HA active/active + fault-tolerant configuration
Date: Wed, 21 Aug 2013 22:49:09 +0200	[thread overview]
Message-ID: <5aa7342b9d8de1d59e048b086d4fd6a9@assyoma.it> (raw)
In-Reply-To: <39187c68-9c18-4a42-bbb6-8704bf3f48a9@theiggy.com>

On 2013-08-21 21:40, Brian Jackson wrote:
> On Wednesday, August 21, 2013 6:02:31 AM CDT, g.danti@assyoma.it 
> wrote:
>> Hi all,
>> I have a question about Linux KVM HA cluster.
>> 
>> I understand that in a HA setup I can live migrate virtual machine 
>> between host that shares the same storage (via various methods, eg: 
>> DRDB). This enable us to migrate the VMs based on hosts loads and 
>> performance.
>> 
>> ìMy current understanding is that, with this setup, an host crash 
>> will cause the VMs to be restarded on another host.
>> 
>> However, I wonder if there is a method to have a fully fault-tolerant 
>> HA configuration, where for "fully fault-tolerant" I means that an 
>> host crash (eg: power failures) will cause the VMs to be migrated to 
>> another hosts with no state change. In other word: it is possible to 
>> have an always-synchronized (both disk & memory) VM instance on 
>> another host, so that the migrated VM does not need to be restarted 
>> but only restored/unpaused? For disk data synchronization we can use 
>> shared storages (bypassing the problem) or something similar do DRDB, 
>> but what about memory?
> 
> 
> You're looking for something that doesn't exist for KVM. There was a
> project once for it called Kemari, but afaik, it's been abandoned for
> a while.

Hi Brian,
thank you for your reply.

As I googled extensively without finding anything, I was prepared to a 
similar response.

Anyway, from what I understand, Qemu already use a similar approach 
(tracking dirty memory pages) when live migrating virtual machines to 
another host.

So what is missing is the "glue code" between Qemu and KVM/libvirt 
stack, right?

Thanks again.

> 
> 
>> 
>> Thank you,
>> regards.
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> 

  reply	other threads:[~2013-08-21 20:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21 11:02 KVM in HA active/active + fault-tolerant configuration g.danti
2013-08-21 19:40 ` Brian Jackson
2013-08-21 20:49   ` g.danti [this message]
2013-08-21 21:47     ` Brian Jackson
2013-08-22  0:35       ` Timon Wang
2013-08-22  6:59         ` g.danti
2013-08-22  3:57     ` Fam Zheng
2013-08-22  7:35 ` Stefan Hajnoczi
2013-08-22  7:42   ` Timon 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=5aa7342b9d8de1d59e048b086d4fd6a9@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=iggy@theiggy.com \
    --cc=kvm@vger.kernel.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 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.