From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLeah-00037c-Gg for qemu-devel@nongnu.org; Wed, 11 Feb 2015 16:13:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLeae-0005Vs-BI for qemu-devel@nongnu.org; Wed, 11 Feb 2015 16:12:59 -0500 Message-ID: <54DBC5D4.4020103@redhat.com> Date: Wed, 11 Feb 2015 14:12:52 -0700 From: Eric Blake MIME-Version: 1.0 References: <54DB96F1.9040003@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fgIw0uoxTPNsU6J6vu9xIaIPSN1OHDSTH" Subject: Re: [Qemu-devel] [libvirt] vm live storage migration with snapshots List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Edward Young Cc: libvirt-users@redhat.com, libvir-list@redhat.com, qemu-devel@nongnu.org, qemu-discuss@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fgIw0uoxTPNsU6J6vu9xIaIPSN1OHDSTH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/11/2015 02:07 PM, Edward Young wrote: >>> What if this vm has a number of disk-only external snapshots? In the >>> current version, how can live migrate this vm? >> >> Are the snapshots based on shared storage, or local-only storage? >> >=20 > Yes, I'm talking about the local-only storage. Okay, glad I guessed as much, then. >=20 > Yes, I agree with you. In this case, we need to migrate the entire disk= > state. In this case, there is no snapshot involved. we just perform the= > regular migration with 'virsh migrate....'. Is this correct? Using 'virsh migrate --copy-storage-all' would indeed migrate the entire disk, if you can't supply shared storage. >>> Or is it possible to iteratively transfer all the snapshots to the >>> destination and later live migrate only the latest new data? >>> >> >> Yes, that works too, and is probably faster, especially if you have >> out-of-band means for sharing read-only state between source and >> destination. >> >=20 > My question is here. If we do not have any shared storage resource betw= een > source and destination (eg. long distance VM migration), how can we mig= rate > the latest new data to the destination? we can copy the base, mid to > destination manually, then how can we migrate the active snapshot( new = data > goes in)? I learned that drive_mirror in qemu is built to finish this, = but > do not understand clearly. Could you elaborate for me, or provide an > example? Use 'virsh migrate --copy-storage-inc' to migrate only the incremental changes, which assumes that the destination can already see the same read-only backing data that the source sees. In fact, modern libvirt/qemu does this for you by setting up an NBD server on the destination, doing a data mirror from the source into the destination (so that you DO have shared storage, at least for the duration of the migration), then doing the live migration, then tearing down the NBD mirroring link. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --fgIw0uoxTPNsU6J6vu9xIaIPSN1OHDSTH 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU28XUAAoJEKeha0olJ0NqYKYH/3nhDpgfBzWbOluSnandlvG1 NKNDId7EEl5npynze43b3oBEzP/sW5zCh02SM/pX/NO46upxNhSpSqisZuoeLoOB v4kVCEV8/s2UM7w2LWuyV71eOTLM1lZVBAY1DGPB821okSjjwODtfgN4fDOzo+kO d8r+XHqCavuTxJB32cxu6dKe7RrWAvt8ShaGjN/Tos94de7SFTBGJ2FAXPSGq3i8 3kBFL30aVf6gUcIda2F40cR9T4mwlmWDcbJPmn08tMfF9QYe1OA/yPWtTIvE585/ aA4eYz1tEsf3B9n8mTqMUg+3XEHM4fZD2w22BdYw5FW+5VHGNMgdRInXjw873Qg= =Gn8U -----END PGP SIGNATURE----- --fgIw0uoxTPNsU6J6vu9xIaIPSN1OHDSTH--