From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bJL-0000bf-Uy for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:03:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4bJG-00029T-9X for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:02:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bJG-000295-1G for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:02:54 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q25H2pjD010319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Mar 2012 12:02:51 -0500 Date: Mon, 5 Mar 2012 13:59:02 -0300 From: Marcelo Tosatti Message-ID: <20120305165902.GC10338@amt.cnet> References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> Subject: Re: [Qemu-devel] Live Block Migration using Mirroring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Federico Simoncelli Cc: kwolf@redhat.com, qemu-devel@nongnu.org On Wed, Feb 22, 2012 at 05:13:32PM +0000, Federico Simoncelli wrote: > Hi, > recently I've been working on live block migration combining the live > snapshots and the blkmirror patch sent by Marcelo Tosatti few months ago. > > The design is summarized at this url as "Mirrored-Snapshot": > > http://www.ovirt.org/wiki/Features/Design/StorageLiveMigration > > The design assumes that the qemu process can reach both the source and > destination storages and no real VM migration between hosts is involved. > The principal problem that it tries to solve is moving a VM to a new > reachable storage (more space, faster) without temporarily disrupting its > services. > > The following set of patches are implementing the required changes in > QEMU. What is the motivation here? What is the limitation with image streaming that this tries to solve? > Here it is a quick example of the use case (for consistency with the > design at the url above I will use the same step numbers): > > Preparation > =========== > > $ mkdir /tmp/{src/dst} > $ qemu-img create -f qcow2 /tmp/src/hd0base.qcow2 20G > Formatting '/tmp/src/hd0base.qcow2', fmt=qcow2 size=21474836480 > encryption=off cluster_size=65536 > > Step 1 - Initital Scenario > ========================== > VM1 is running on the src/hd0base. (Where "<=" stands for "uses") > > [src/hd0base] <= VM1(read-write) > > $ qemu-system-x86_64 -hda /tmp/src/hd0base.qcow2 -monitor stdio > QEMU 1.0.50 monitor - type 'help' for more information > (qemu) > > Step 3 - Mirrored Live Snapshot > =============================== > A mirrored live snapshot is issued using src/hd0snap1 and dst/hd0snap1 as > image files. (Where "<-" stands for "has backing file") > > [src/hd0base] <- [src/hd0snap1] <= VM1(read-write) > ... <- [dst/hd0snap1] <= VM1(write-only) > > $ qemu-img create -f qcow2 \ > -b /tmp/src/hd0base.qcow2 /tmp/src/hd0snap1.qcow2 20G > Formatting '/tmp/src/hd0snap1.qcow2', fmt=qcow2 size=21474836480 > backing_file='/tmp/src/hd0base.qcow2' encryption=off cluster_size=65536 > > $ qemu-img create -f qcow2 \ > -b /tmp/dst/hd0base.qcow2 /tmp/dst/hd0snap1.qcow2 20G > Formatting '/tmp/dst/hd0snap1.qcow2', fmt=qcow2 size=21474836480 > backing_file='/tmp/src/hd0base.qcow2' encryption=off cluster_size=65536 > > (qemu) snapshot_blkdev -n ide0-hd0 \ > blkmirror:/tmp/src/hd0snap1.qcow2:/tmp/dst/hd0snap1.qcow2 blkmirror > > Step 4 - Backing File Copy > ========================== > An external manager copies src/hd0base to the destination dst/hd0base. > > [src/hd0base] <- [src/hd0snap1] <= VM1(read-write) > [dst/hd0base] <- [dst/hd0snap1] <= VM1(write-only) > > $ cp -a /tmp/src/hd0base.qcow2 /tmp/dst/hd0base.qcow2 > > Step 5 - Final Switch to Destination > ==================================== > VM1 is now able to switch to the destination for both read and write > operations. > > [src/hd0base] <- [src/hd0snap1] <= VM1(read-write) > > (qemu) snapshot_blkdev -n ide0-hd0 /tmp/dst/hd0snap1.qcow2 > > -- > Federico