From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLbT7-000579-DX for qemu-devel@nongnu.org; Wed, 11 Feb 2015 12:53:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLbT4-0006jd-5j for qemu-devel@nongnu.org; Wed, 11 Feb 2015 12:52:57 -0500 Message-ID: <54DB96F1.9040003@redhat.com> Date: Wed, 11 Feb 2015 10:52:49 -0700 From: Eric Blake MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2en2AbMe5Jm5ISufkgpwRMMrns2a7rxhQ" 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 , libvirt-users@redhat.com, qemu-discuss@nongnu.org, qemu-devel@nongnu.org, libvir-list@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2en2AbMe5Jm5ISufkgpwRMMrns2a7rxhQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/11/2015 10:08 AM, Edward Young wrote: > Hi all, [probably didn't need to cross-post to quite that wide of an audience, oh well] >=20 > I'm investigating the ways to improve the live migration performance in= > libvirt. I have a question about the vm live storage migration. the > platform is libvirt + qemu + kvm >=20 > If we want to migrate a running vm with its virtual disk images to anot= her > node. > we can use 'virsh migrate ....' commands. >=20 > 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? If I understand your question correctly, you are starting with this situation: base <- mid <- active and want to make sure that on the destination, the guest still sees the same contents as 'active' on the source, whether or not the destination still sees a backing chain or just one file. >=20 > Is it possible to blockcommit the snapshots to the base image and later= > perform the migration, without shutting down the running vm? Yes, but that may not be the fastest solution. That is, you would be going from: base <- mid <- active to base' where base' is the active image containing all the committed state, then migrate that file. If base is not shared, that means qemu has to migrate the entire disk state. And you also no longer have the external snapshots to revert to on the destination. >=20 > Or is it possible to iteratively transfer all the snapshots to the > destination and later live migrate only the latest new data? >=20 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. In fact, if you can create yet another (temporary) external snapshot, but this time on shared storage, and have storage backends that let you instantly remap backing files to be visible into the destination, then it is as simple as: create a snapshot with shared storage destination base <- mid <- active(frozen) <- shared copy base, mid, and active to the destination live migrate using shared storage instead of doing storage migration block-commit shared back into active base <- mid <- active where the shared storage only needs to hold as much disk state as diverges during the time of the live migration. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --2en2AbMe5Jm5ISufkgpwRMMrns2a7rxhQ 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/ iQEcBAEBCAAGBQJU25bxAAoJEKeha0olJ0NqLj0H/1pP0Z7v6KSz7J6i+0ssTKBG /1zG5kJ0RbPj9YHNPnFfmIrOVu3paD91qb1GuAcazqk2mdSgp70sAKcY4r21eeLJ HpDc3/FNnkGN3CpfpzV5gQ26vzfSGWJ6q1Fsc98Vh3cZYHHSoC3Mp44clcGZbu4V aaRaXShkyInUT3RRGInE6a83U9TDdB5ExR2T4302bQCB8477+6byJ/yK/Bb6Uejn M4EDN9JIjG2OwSsYjm4Wusi3etGcqx+MB9/jwIjwT33UQqMsud/RqtVaVor4Wfc1 Fo/1klinU3AxRF0RxCR9bUCcRPsX4V3xeTNqPVx7H8IqVVUxD5ijqa2NyRLDGoU= =gRGx -----END PGP SIGNATURE----- --2en2AbMe5Jm5ISufkgpwRMMrns2a7rxhQ--