From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOVL4-0007Ac-5I for qemu-devel@nongnu.org; Wed, 27 Jan 2016 14:01:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOVL0-0001MI-W5 for qemu-devel@nongnu.org; Wed, 27 Jan 2016 14:01:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOVL0-0001MD-O0 for qemu-devel@nongnu.org; Wed, 27 Jan 2016 14:01:06 -0500 References: From: Max Reitz Message-ID: <56A913EF.6060200@redhat.com> Date: Wed, 27 Jan 2016 20:01:03 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uafcC8ELNLPq8m4P9G7Ug46dqh90OgrtE" Subject: Re: [Qemu-devel] QCOW rebases on running VMs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uafcC8ELNLPq8m4P9G7Ug46dqh90OgrtE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 27.01.2016 19:04, Alex Bligh wrote: > This question concerns the safety of rebases on backing disks whilst a = VM is running from a writing disk. >=20 > Assume that we have the following structure: >=20 > QEMU -------> Writing disk > .... > backing disk N > .... > backing disk 1 > .... > backing disk 0 >=20 > If QEMU is not running, I can happily use 'qemu-img rebase' to merge ba= cking disks 1 ... N (i.e. so backing disk N is now based on backing disk = 0). >=20 > Is it safe to do this whilst the server is running using the writing di= sk which is based on backing disk N? Maybe. You would rebase 1 through N into a new file and change the backing file of the writing disk to the new file; because qemu is not writing to the backing disks, that should probably work, but it's not nice and may break horribly without prior notice. > It is attractive to think it might be, as even if QEMU has a stale view= of the contents of backing disk N, backing disks N-1 to 1 (inclusive) wi= ll still be present, QEMU will still keep an fd open for them, and it wil= l (thus) still be able to read the correct sectors from them. >=20 > If not, do I need to use QMP magic instead? This is always the best option, and I would strongly recommend doing so. block-stream or block-commit should be your friend. block-stream streams data from backing files into backed files, block-commit pushes data from backed files into backing files; so block-stream transmits data from bottom to top, and block-commit transmits it from top to bottom. With block-commit, you can collapse the backing chain to e.g. (from top to bottom): Writing disk -> backing disk 1..N -> backing disk 0 like this (I think): { 'execute': 'block-commit', 'arguments': { 'device': '$drive', 'base': 'backing disk 1', 'top': 'backing disk N' } } The "backing disk 1..N" is the file which contained "backing disk 1" and now contains all the data from disks 1 through N. With block-stream, you can collapse it into Writing disk -> backing disk 0 like this: { 'execute': 'block-stream', 'arguments': { 'device': '$drive', 'base': 'backing disk 0' } } Here, the writing disk would contain all the data from backing disks 1 through N. You could omit the "base" option, in which case the whole backing chain would be collapsed into the writing disk. Max --uafcC8ELNLPq8m4P9G7Ug46dqh90OgrtE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWqRPvAAoJEDuxQgLoOKytfmMIAKB5xJTZc/+nw63THfoeU9xI b2D8mqEjXjpKOOCZeiujq6s1lt8Z/32a4cB6z6mWL57kuOaxjVw9e6FeFmOnTwxF kWpO4RJCHPnvMipMiywkXLfB5kMdlqDUbblL2ij55sbyMolerUmlTvPa/Bw2ugW6 sOYgabkoEHJHT+pzcXS8Wvo54vIueb0w6I3uyG8QrO2FR2ggbK+oJXGPem8aMTa1 /Ed8/mHlG+O7LVEiiuw58PAhH70e1prwexdu3UjJR5eVZ8t7zLo+XlKJnEwftcgG GIihpFJD3upk82TbB2lcRwbA0H0V35i41un+7e/AK9xTVY3KpVIeJS16FJy4B8o= =84Ct -----END PGP SIGNATURE----- --uafcC8ELNLPq8m4P9G7Ug46dqh90OgrtE--