From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJgps-0007ix-1N for qemu-devel@nongnu.org; Thu, 14 Jan 2016 07:17:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJgpr-0002oe-7h for qemu-devel@nongnu.org; Thu, 14 Jan 2016 07:17:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJgpq-0002oa-T0 for qemu-devel@nongnu.org; Thu, 14 Jan 2016 07:17:03 -0500 Date: Thu, 14 Jan 2016 13:17:00 +0100 From: Kevin Wolf Message-ID: <20160114121700.GB4084@noname.redhat.com> References: <6ca84848.f052.15211b20317.Coremail.magazine.lihuiba@163.com> <568BCB6C.7010709@redhat.com> <557a47a5.3564.15214d76e2e.Coremail.magazine.lihuiba@163.com> <568D2D00.3050600@redhat.com> <568D3EDD.1090205@redhat.com> <568D40AC.5050901@redhat.com> <568D4109.5060107@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <568D4109.5060107@redhat.com> Subject: Re: [Qemu-devel] qcow2 snapshot + resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: lihuiba , "qemu-devel@nongnu.org" --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 06.01.2016 um 17:30 hat Max Reitz geschrieben: > On 06.01.2016 17:28, Eric Blake wrote: > > On 01/06/2016 09:20 AM, Max Reitz wrote: > >=20 > >>> If I take a snapshot while the guest sees a 1G disk, then resize the > >>> disk to 2G, then roll back to the point in time of the snapshot, I'd > >>> expect the disk to roll back to 1G in size. Anything else is likely = to > >>> confuse the guest. And that's what current resize support already do= es > >>> (it only resizes the active image, not the snapshots). > >> > >> No, the current resize operation just refuses to resize the image if it > >> has any snapshots. Snapshots currently do not store the size of the > >> image when they were created. > >=20 > > Huh? I thought that we specifically added bytes 48-55 per snapshot entry > > in the qcow2v3 description specifically so that internal snapshots DO > > record the size of the image when the snapshot was created. >=20 > Oh, you're right! Well, then that was probably the intention, yes. > However, resizing an image with snapshots will still fail. I guess the only thing that would need to implement something new is qcow2_snapshot_goto(), which currently refuses to load a snapshot that has a different disk size. Once this is done, just removing the check in qcow2_truncate() should be okay. Kevin --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWl5G8AAoJEH8JsnLIjy/WzXgP/3z6FA5j8eC7sc5p4bJKFitx 3y8IaNi0qmPjLDWVY7gV1uQW4HW4jUW6G/F0lvSCgUb+30cz230h0z+d5PnSb20Z uzUNKvf6KCwSBqEFarGyyW2hK2aPEdsaGY++1l1hcTS6VwiQH0Qf+GyVO8GLKKEC qeZq4x3/PZe2aD82CuP7M/xJWFMj5lUweV/cqkneuCmm6XdCthALGeVS8DoqWiUb BUfjd1G04dxal66FxmGPzlqWhS2/SJxLskraWUd4TQBNMeIgG2G4BSP95FmK21jU 9HhdK3+FwKK72FlIEKO++BKpTcKfazHb6ZaEeym8ySLnagmEKXQeoEatxgMaPUKh +qpTwTZoBSVOX7rVJu6OcWfq1B+7YjTU3/u8xJMBNgOhYCIo+fONsIrKa3DHNRBC Dd0om52EjoXOS6zLZdu88JZUpeU/0dKUbfGiDYRGtjAsBqNCFaFrrQ45/FDV1etA OZqDFulVSzYu1wsBpvaqt1ShcH5ixn4whz+8Jufbzj7mV9ixmK4a7+luecMgbH0B YckqM+/t82PqNG/JOfYEyYoBDODHwQPWf4FaYEiwbCtZ/vFr8i4ZVNil0TBsb8I6 FxsNm3LYJeHMzyCjN8kISuHEHX1lN9ZYK/1wZ6Rh9bPngT4r1mdcdn5X+Dewi7IY ZzfH1uZLcclyU4iuD7tV =WSd4 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi--