From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXBZB-0004k9-Mi for qemu-devel@nongnu.org; Thu, 25 Sep 2014 12:06:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXBZ2-00070B-Lj for qemu-devel@nongnu.org; Thu, 25 Sep 2014 12:06:49 -0400 Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:38565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXBZ2-0006zR-DO for qemu-devel@nongnu.org; Thu, 25 Sep 2014 12:06:40 -0400 Received: by mail-la0-f53.google.com with SMTP id ty20so365249lab.40 for ; Thu, 25 Sep 2014 09:06:34 -0700 (PDT) Message-ID: <54243D87.4030909@gmail.com> Date: Thu, 25 Sep 2014 18:06:31 +0200 From: Walid Nouri MIME-Version: 1.0 References: <1407587152.24027.5.camel@usa> <53E8FBBD.7050703@gmail.com> <53E92470.60806@linux.vnet.ibm.com> <53F07B73.60407@redhat.com> <54107187.8040706@gmail.com> <20140911174407.GP2353@work-vm> <20140912110735.GG1614@stefanha-thinkpad.redhat.com> <5419F4CC.2060903@gmail.com> <20140918135604.GB16227@stefanha-thinkpad.redhat.com> <5421A19A.9090201@gmail.com> <20140924084732.GB21137@stefanha-thinkpad.redhat.com> In-Reply-To: <20140924084732.GB21137@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Microcheckpointing: Memory-VCPU / Disk State consistency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, eddie.dong@intel.com, "Dr. David Alan Gilbert" , "Michael R. Hines" , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini , yanghy@cn.fujitsu.com Am 24.09.2014 10:47, schrieb Stefan Hajnoczi: > I think the assumption with drive-mirror is that you throw away the > destination image if something fails. That's the exact opposite of MC > where we want to fail over to the destination :). This was not obivous for me... > Here is one example of a mechanism like this: > > QEMU has a block job called drive-backup which copies sectors that are > about to be overwritten to an external file. Once the data has been > copied into the external file, the sectors in the original image file > can be overwritten safely. > > The Secondary runs drive-backup so that writes coming from the Primary > stash rollback data into an external qcow2 file. When the Primary > wishes to commit we drop the qcow2 rollback file since we no longer need > the ability to roll back - this is cheap and not a lot of I/O needs to > be performed for the commit operation. > > If the Secondary needs to take over it can use the rollback qcow2 file > as its disk image and the guest will see the state of the disk at the > last commit point. The sectors that were modified since commit in the > original image file are covered by the data in the rollback qcow2 file. > > There are a bunch of details on making this efficient but in principle > this approach makes both commit and rollback fairly lightweight. > Until yesterday I’ve seen backup as mechanism that makes a point in time snapshot of a block device and saves the contents of that snapshot to an other block device. Your proposal is a new interpretation of backup :-) I must admit that I had to think twice to get an idea what your point is. I don’t know if I have understood all aspects of your proposal as my mental model of a possible architecture is not quite clear yet. I will try to summarize in “MC-words” what I have understood: The general Idea is to use drive-backup to get a consistent snapshot of a mirrored block device on the secondary for a given period of time I will call it epoch(n) and snapshot(n). As a starting point we need to block-devices with exact the same state on primary and secondary. In other word there must be an exact copy of the primary image on the secondary. In epoche(n) the primary mirror its writes to the image file of secondary. This leads to a continuous stream of updated blocks to the image of the secondary. In parallel the secondary use drive-backup to get a rollback-snapshot(n) its own image file for each running epoche. At the beginning of epoche(n+1) we start a (new) rollback-snapshot(n+1) and keep rollback-snapshot(n). When in normal operation we drop rollback-snapshot(n) when epoche(n+1) is successfully completed. In case of a failure in epoche(n+1) we make a fail over and use rollback-snapshot(n) to get back the consistent block device state of epoche(n) Is this your idea? Does this procedure guaranty the block-device semantics of the primary? Walid