From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWjoS-0008Bj-NS for qemu-devel@nongnu.org; Tue, 01 Sep 2015 07:33:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWjoR-0002df-Jw for qemu-devel@nongnu.org; Tue, 01 Sep 2015 07:33:16 -0400 Date: Tue, 1 Sep 2015 13:33:07 +0200 From: Kevin Wolf Message-ID: <20150901113307.GC4304@noname.redhat.com> References: <457103c2204e849aea3b83ffd78fad049d8d923d.1441014844.git.berto@igalia.com> <55E4B0CC.6070906@redhat.com> <55E4B374.70800@redhat.com> <55E4B513.5040600@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <55E4B513.5040600@redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blockdev-snapshot-sync List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Alberto Garcia , qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 31.08.2015 um 22:12 hat Max Reitz geschrieben: > On 31.08.2015 22:05, Eric Blake wrote: > > On 08/31/2015 01:53 PM, Max Reitz wrote: > >=20 > >> Design question: Would it make sense to instead add a "reference" mode > >> to blockdev-snapshot-sync where you can specify a BDS's node-name > >> instead of snapshot-file to use an existing BDS as the new top layer, > >> ideally an empty one? > >=20 > > Indeed - then blockdev-add can be used to create an unattached BDS (with > > all appropriate options), and blockdev-snapshot-sync would then attach > > that BDS as the snapshot-file that wraps an existing BDS (without > > needing to worry about options). > >=20 > >> > >> What we'd then need is a QMP command for creating images. But as far as > >> I know we'll need that anyway sooner or later... > >=20 > > Can't blockdev-add already be used for that (at least, for supported > > file types)? If not, what would it take to get it there? >=20 > It would take a blockdev-create-image QMP command. :-) >=20 > blockdev-add only opens existing images, blockdev-create-image would > then create these so they can be opened using blockdev-add. >=20 > Similar to blockdev-add, it would probably have a single parameter, but > it'd be of a different type, called e.g. BlockdevCreateOptions, since it > has to reflect the creation options instead of the runtime options for > opening existing images. For instance, for qcow2 you could set the > refcount-bits value, but not the L2 cache size. Would be nice to have (especially because we would get a schema of the create options), but not absolutely necessary for a blockdev-* style snapshotting command. libvirt seems to cope just fine with calling qemu-img before going to the QMP monitor. Kevin --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV5YzzAAoJEH8JsnLIjy/WrOcP/RoKqC+iEW819uTtkNP5Mu58 mq206abV/5/BfMCFbRpM0AzGhHVdIq2FNKzzKQz6s2829j9Cx3eckI3RG9ogCKQF gYsHQH8vO0b49IT0v/kB9dKqZeDAYdDfFzDowpFbnjMptC2HLrxMTlIMtnDBEeAZ 8vXrrF/ePrs4uzmqrispxwClGQYY6H8cqqIgs25lpgx546/dWvjQCCxJKDq4s5Ro YMxct1cREUFj3ju4xEY5j8WIGwTIKLjWuj3vNuUCVGAHA6shyzPYF4MAr5fsDOq4 G9FdJUGHMVbJMcQp6y4/wMkJv4GlJUZF/4BVi7de7yo8QfkgrWP36h9xQ+SzXj2O EjmncQHF3P9/dfdd2peRC+i1JhOYDZfaPFvD997m9hVZ3m5Q4yUktg2/a91cuxA9 OxkhqbIyFvMfB6y2p/qUUBuPpocz8mx+w/ypfHbtfP2tJivwzsxOrhysXvnousx/ GOcFPU8OWXLlQ3lwFhxaF+HH4/JUWPmbvvZ+mnIRC9WOhoiQAiVENRC2/K5qiTdB cMRapmA5Sj4nYKQwnk/zeX6i3qafTZ3Wcr3ReZ8LL/+Wlc+KaB+6cyVpN/+WIfVj KV1XnMwooi3kKt0TbhygQX3KrZGXw4BfcuxKztA5DEyLUIT/FQuBju9UbZqTUmYo PgKlbgsYkFBVnzeHCXn2 =3cio -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o--