From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUJMB-0006Nn-Bm for qemu-devel@nongnu.org; Fri, 02 Nov 2012 11:40:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUJM8-0007hu-HU for qemu-devel@nongnu.org; Fri, 02 Nov 2012 11:40:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUJM8-0007hE-8L for qemu-devel@nongnu.org; Fri, 02 Nov 2012 11:40:24 -0400 Message-ID: <5093E95F.2070101@redhat.com> Date: Fri, 02 Nov 2012 09:40:15 -0600 From: Eric Blake MIME-Version: 1.0 References: <20121102.172447.47346577.k.suzaki@aist.go.jp> <5093C6B5.7070901@redhat.com> <20121103.000020.17416294.k.suzaki@aist.go.jp> In-Reply-To: <20121103.000020.17416294.k.suzaki@aist.go.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE5031C3725F299254EB01ADE" Subject: Re: [Qemu-devel] live migration which includes previos snapshot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kuniyasu Suzaki Cc: stefanha@gmail.com, qemu-devel@nongnu.org, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5031C3725F299254EB01ADE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/02/2012 09:00 AM, Kuniyasu Suzaki wrote: >> You are not the first to request this - libvirt would also like the >> ability to have read-only access into the contents of an internal >> snapshot while the rest of qemu continues to write into the image. >=20 > Do you mean that libvirt can change the access mode of internal > harddisk from read-write to read-only? No. I meant that reading an internal snapshot (a read-only operation) while still using the rest of the qcow2 file read-write for live operation would be a nice feature. The very nature of the qcow2 file format means that you cannot have two writers at the same time; the best you can do is expose the snapshots as a read-only backing file of yet another qcow2 file if you want a second writer based on the state of the snapshot without interfering with the first writer. > Please tell me how to change the mode by libvirt. Libvirt can't support reading of internal snapshots until qemu supports it. In other words, it's a feature no one has written yet, but which several people want. >=20 > Does the qemu which has read-only access only, use another COW file? > Nested COWs sound interested, but the inter COW must be read-only, I th= ink. Correct - any reading of internal snapshots must be read-only - you are required to use external backing files before you can have multiple writers sharing a common backing file. >=20 >>> 2. Use Paolo's runtime NBD server to export the snapshot slave when >>> the VM is forked: >> >> An NBD server on top of the read-only state is an additional step that= >> will make access easier. >=20 > Does an NBD work as COW? It looks convenient. Rather, I'm thinking of making the NBD of the read-only internal snapshot be the backing file of the new qcow2 layer. But yes, NBD is probably the best way for qemu to expose the contents of an internal snapshot, rather than inventing yet another protocol. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigE5031C3725F299254EB01ADE 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://www.enigmail.net/ iQEcBAEBCAAGBQJQk+lfAAoJEKeha0olJ0Nq5q0H/ivtHAOeNUa66F+3Umj951vL t6J4rH+ig8FjjF2Wpx1il+onIhv3TDgJNdO87QfMPncjFcWmg58ovLc5jeVxYw2h nXuPndikMiHxmlKPNgFHeP7tD3ifdIjnl368HyU0iDxH7curGJ1eMhp2dImQNMxo LKPJlIb4X31W3MZA8gQyqqqSVx74YgC9ncOHY2VP5FUIBp0r1XHh9nkS0kPPfMcX kCzHfoU+jZrhH1CeRJVm5cRKeBMEx9RKlVBGB5naAt4XCA6RCdci0bUtusqH9192 MxclITluwcjsrfDubkIkw+Y4RhN8TUBL7E+vnHS+Z4YBtCvE+3GKCX315GBWdmA= =tgtX -----END PGP SIGNATURE----- --------------enigE5031C3725F299254EB01ADE--