From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2PaP-00059r-Jk for qemu-devel@nongnu.org; Tue, 28 Feb 2012 11:07:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2PaJ-0008Cj-0u for qemu-devel@nongnu.org; Tue, 28 Feb 2012 11:07:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2PaI-0008CO-P6 for qemu-devel@nongnu.org; Tue, 28 Feb 2012 11:07:26 -0500 Message-ID: <4F4CFBB7.9060707@redhat.com> Date: Tue, 28 Feb 2012 09:07:19 -0700 From: Eric Blake MIME-Version: 1.0 References: <87r4xg1n5g.fsf@elfo.elfo> <4F4BBBA8.3020105@redhat.com> <4F4BFC9A.1020300@redhat.com> <4F4BFE4D.8000409@codemonkey.ws> <4F4CE8FB.8080404@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig1C6BFBAFEDE8D5966AC675E3" Subject: [Qemu-devel] blockdev operations [was: KVM call agenda for Tuesday 28th] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: KVM devel mailing list , Jeff Cody , Developers qemu-devel , Federico Simoncelli , quintela@trasno.org, Anthony Liguori , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C6BFBAFEDE8D5966AC675E3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote: > On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini wr= ote: >> Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto: >>> I'm not a fan of transactions or freeze/thaw (if used to atomically >>> perform other commands). >>> >>> We should not export low-level block device operations so that >>> external software can micromanage via QMP. I don't think this is a >>> good idea because it takes the block device offline and possibly >>> blocks the VM. We're reaching a level comparable to an HTTP interfac= e >>> for acquiring pthread mutex, doing some operations, and then another >>> HTTP request to unlock it. This is micromanagement it will create >>> more problems because we will have to support lots of little API >>> functions. >> >> So you're for extending Jeff's patches to group mirroring etc.? >> >> That's also my favorite one, assuming we can do it in time for 1.1. >=20 > Yes, that's the approach I like the most. It's relatively clean and > leaves us space to develop -blockdev. Here's the idea I was forming based on today's call: Jeff's idea of a group operation can be extended to allow multiple operations while reusing the framework. For oVirt, we need the ability to open a mirror (by passing the mirror file alongside the name of the new external snapshot), as well as reopening a blockdev (to pivot to the other side of an already-open mirror). Is there a way to express a designated union in QMP? I'm thinking something along the lines of having the overall group command take a list of operations, where each operation can either be 'create a snapshot', 'create a snapshot and mirror', or 'reopen a mirror'. I'm thinking it might look something like: { 'enum': 'BlockdevOp', 'data': [ 'snapshot', 'snapshot-mirror', 'reopen' ] } { 'type': 'BlockdevAction', 'data': {'device': 'str', 'op': 'BlockdevOp', 'file': 'str', '*format': 'str', '*reuse': 'bool', '*mirror': 'str', '*mirror-format': 'str' } } { 'command': 'blkdev-group-action-sync', 'data': { 'actionlist': [ 'BlockdevAction' ] } } The overall command is atomic - either all operations will succeed, or the command returns an error pointing to the name of the device that failed leaving all devices in their pre-command state. Then, for each requested operation: If op is 'snapshot', then 'file' names the new snapshot file; 'reuse' is optional (defaults to false) to say whether qemu creates the file from scratch, or opens an existing file with the backing file already populated correctly. 'format' gives the format of 'file', defaulting to qcow2. 'mirror' and 'mirror-format' must not be given. If op is 'snapshot-mirror', then 'mirror' is mandatory; and both 'file' and 'mirror' are opened as a new mirrored snapshot. Again, 'reuse' affects whether qemu creates the new files from scratch or trusts oVirt to pre-create both files with backing file information; and 'format' and 'mirror-format' allow control over the image format being opened. If op is 'reopen', then 'file' is the name of the file to be opened to replace the current file tied to the blockdev, with type given by 'format'. 'reuse', 'mirror', and 'mirror-format' must not be given. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig1C6BFBAFEDE8D5966AC675E3 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://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPTPu3AAoJEKeha0olJ0NqVzEH/3aH5VG1NuVnSKwb7PGumkSi KSaYM2KvEvSPMzQaEf7KNtQDfQwmSpMfoD604pxUv0K3bFaTvKphyYxSb5vUK3u5 DuGcjkMHbdalnoLIQj0vtyPmXDupfJhnuT0lBF5mysTfq1s145V8r66fpLkh2N8s 0fUhOJE5Gf4I7teOW008IzZuQwaNS84fdbEXQT4BnunEuDiHF140Ryfr173Kih6j 1GLHPdw8+GrTRcVsjv48p+GNviKYKslixDITXfXT7f+VhprPURb2hs3h7exOu4vE 21zo645+F8N3AraNOCvqi0NcUnZJfi5WPDe5qzxwDKW40AuXVOR+Gt16GXszrBA= =f1tV -----END PGP SIGNATURE----- --------------enig1C6BFBAFEDE8D5966AC675E3--