From mboxrd@z Thu Jan 1 00:00:00 1970 From: g.danti@assyoma.it Subject: Re: KVM in HA active/active + fault-tolerant configuration Date: Wed, 21 Aug 2013 22:49:09 +0200 Message-ID: <5aa7342b9d8de1d59e048b086d4fd6a9@assyoma.it> References: <39187c68-9c18-4a42-bbb6-8704bf3f48a9@theiggy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: To: Brian Jackson Return-path: Received: from santino.mail.tiscali.it ([213.205.33.245]:43438 "EHLO santino.mail.tiscali.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752933Ab3HUUt1 (ORCPT ); Wed, 21 Aug 2013 16:49:27 -0400 In-Reply-To: <39187c68-9c18-4a42-bbb6-8704bf3f48a9@theiggy.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2013-08-21 21:40, Brian Jackson wrote: > On Wednesday, August 21, 2013 6:02:31 AM CDT, g.danti@assyoma.it=20 > wrote: >> Hi all, >> I have a question about Linux KVM HA cluster. >>=20 >> I understand that in a HA setup I can live migrate virtual machine=20 >> between host that shares the same storage (via various methods, eg:=20 >> DRDB). This enable us to migrate the VMs based on hosts loads and=20 >> performance. >>=20 >> =C3=ACMy current understanding is that, with this setup, an host cra= sh=20 >> will cause the VMs to be restarded on another host. >>=20 >> However, I wonder if there is a method to have a fully fault-toleran= t=20 >> HA configuration, where for "fully fault-tolerant" I means that an=20 >> host crash (eg: power failures) will cause the VMs to be migrated to= =20 >> another hosts with no state change. In other word: it is possible to= =20 >> have an always-synchronized (both disk & memory) VM instance on=20 >> another host, so that the migrated VM does not need to be restarted=20 >> but only restored/unpaused? For disk data synchronization we can use= =20 >> shared storages (bypassing the problem) or something similar do DRDB= ,=20 >> but what about memory? >=20 >=20 > 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=20 similar response. Anyway, from what I understand, Qemu already use a similar approach=20 (tracking dirty memory pages) when live migrating virtual machines to=20 another host. So what is missing is the "glue code" between Qemu and KVM/libvirt=20 stack, right? Thanks again. >=20 >=20 >>=20 >> 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 >>=20 >>=20