From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4baY-0006b3-GM for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:20:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4baR-0007Hw-SV for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:20:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4baR-0007Hm-Kt for qemu-devel@nongnu.org; Mon, 05 Mar 2012 12:20:39 -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 q25HKcUx019602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Mar 2012 12:20:38 -0500 Message-ID: <4F54F5E4.4050206@redhat.com> Date: Mon, 05 Mar 2012 10:20:36 -0700 From: Eric Blake MIME-Version: 1.0 References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> <20120305165902.GC10338@amt.cnet> In-Reply-To: <20120305165902.GC10338@amt.cnet> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigCCB2DBED654C03723100B88B" Subject: Re: [Qemu-devel] Live Block Migration using Mirroring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: kwolf@redhat.com, Federico Simoncelli , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCCB2DBED654C03723100B88B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/05/2012 09:59 AM, Marcelo Tosatti wrote: > 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 a= go. >> >> The design is summarized at this url as "Mirrored-Snapshot":=20 >> >> 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 involve= d. >> 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. >=20 > What is the motivation here? What is the limitation with image streamin= g > that this tries to solve? My understanding is that this solves the scenario of a storage failure during the migration. The original post-copy approach has the flaw that you are setting up a situation where qemu is operating on a qcow2 file on one storage domain that is backed by a file on another storage domain. After you start the migration process, but before it completes, any failure in the migration is fatal to the domain: if the destination storage domain fails, then you have lost all the delta changes made since the migration started. And after the migration has completed, you still have the problem that qemu is crossing storage domains - if the source storage domain fails, then qemu's access to the backing file renders the destination qcow2 worthless, so you cannot shut down the source storage domain without also restarting the guest. But a mirrored solution does not have these drawbacks - at all points through the migration phase, you are guaranteed that _all_ data is accessible from a single storage domain. If the destination storage fails, you still have the source storage intact, and can restart the migration process. Then, when the migration is complete, you tell qemu to atomically switch storage domains, at which point the entire storage is accessed from the destination domain, and you can safely shut down the source storage domain while the guest continues to run.. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigCCB2DBED654C03723100B88B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPVPXkAAoJEKeha0olJ0NqsKEH/0Vj7WGjSSKONtGcI1/R5Djl jM9WDqPJV3xZubOfhTBxdXEWwSKF34K0A8onBWsBQxqwAPSGivThApctJFeFu1rt pgIo/je4BmsuXEO4S/ZJBJra4FWomAk717o3PSurksyB/sVYp81kq05yy+8DgQjo j/cy135Vey4kKj+sk/u42DXisBEAb36KelW6B13XupjYTTV6VY/zh1BTrkKd+5Kw 6nvWLMallCxspJw+BKxLUnHEYK3RPDkyV+flmwE5idX8FNrIe2fzZYp1Wpic7oOV gJX+PIGPyQ2xxNRo3l7LsE13pBUWSdiER7c9sznTA1SbM/ZAXPBH3lCGfq/ZsRg= =xKjL -----END PGP SIGNATURE----- --------------enigCCB2DBED654C03723100B88B--