From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7nzN-0007dw-0m for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:12:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7nyx-0001se-Dr for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:11:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7nyx-0001sZ-5d for qemu-devel@nongnu.org; Wed, 14 Mar 2012 09:11:11 -0400 Message-ID: <4F6098E5.4010709@redhat.com> Date: Wed, 14 Mar 2012 07:11:01 -0600 From: Eric Blake MIME-Version: 1.0 References: <6a335e17-f79d-4caf-81fa-6d8b0130a0a6@zmail16.collab.prod.int.phx2.redhat.com> <4F606610.3030809@redhat.com> In-Reply-To: <4F606610.3030809@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig91363A8330C521674A4BCD2E" Subject: Re: [Qemu-devel] [PATCH v4 10/10] Add the drive-reopen command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: stefanha@linux.vnet.ibm.com, Markus Armbruster , qemu-devel@nongnu.org, lcapitulino@redhat.com, Federico Simoncelli , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig91363A8330C521674A4BCD2E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/14/2012 03:34 AM, Kevin Wolf wrote: >> That said, reopen is really hard to be implemented as a transaction >> without breaking that rule. For example in the blkmirror case you'd >> need to open the destination image in r/w while the mirroring is in >> action (already having the same image in r/w mode). >> >> There are several solutions here but they are either really hard to >> implement or non definitive. For example: >> >> * We could try to implement the reopen command for each special case, >> eg: blkmirror, reopening the same image, etc... and in such cases >> reusing the same bs that we already have. The downside is that this >> command will be coupled with all this special cases. >=20 > The problem we're trying to solve is that we have a graph of open > BlockDriverStates (connected by bs->file, backing file relations etc.) > and we want to transform it into a different graph of open BDSs > atomically, reusing zero, one or many of the existing BDSs, and possibl= y > with changed properties (cache mode, read-only, etc.) >=20 > What we can have reasonably easily (there are patches floating around, > they just need to be completed), is a bdrv_reopen() that changes flags > on one given BDS, without changing the file it's backed by. This is > already broken up into prepare/commit/abort stages as we need it to > reopen VMDK's split images safely. >=20 > In theory this should be enough to build the new graph by opening yet > unused BDSs, preparing the reopen of reused ones and only if all of tha= t > was successful, committing the bdrv_reopen and changing the relations > between the nodes. I hope that at the same time it's clear that this > isn't exactly trivial to implement. Agreed that 1) it looks implementable, and 2) it does not look trivial. >=20 >> * We could use the transaction APIs without actually making it >> transaction (if we fail in the middle we can't rollback). The only >> advantage of this is that we'd provide a consistent API to libvirt >> and we would postpone the problem to the future. Anyway I strongly >> discourage this as it's completely unsafe and it's going to break >> the transaction semantic. Moreover it's a solution that relies too >> much on the hope of finding something appropriate in the future. >=20 > This is not an option. Advertising transactional behaviour and not > implementing it is just plain wrong. Absolutely concur. From libvirt's perspective, I will be assuming that: if 'transaction' exists, then it supports 'blockdev-snapshot-sync' and 'drive-mirror' (assuming that these are the only two commands that are in 'transaction' in qemu 1.1), but nothing else is safe to use without a further probe. Then, if down the road, we go through the pain of making 'drive-reopen' transactionable, then there will be some new introspection command (one idea was an optional argument to query-commands which limits output to just the commands that can also occur in a 'transaction'), and libvirt will have to use that introspection before using the additional features. >=20 >> * We could leave it as it is, a distinct command that is not part of >> the transaction and that it's closing the old image before opening >> the new one. >=20 > Yes, this would be the short-term preliminary solution. I would tend to= > leave it to downstreams to implement it as an extension, though. Correct - I'm fine with libvirt using the direct, non-atomic, 'drive-reopen' for the immediate needs of oVirt while we work on a more complete solution for down the road. >=20 >> This is not completely correct, the main intent was to not spread one >> image chain across two storage domains (making it incomplete if one of= >> them was missing). In the next oVirt release a VM can have different >> disks on different storage domains, so this wouldn't be a special case= >> but just a normal situation. >=20 > The problem with this kind of argument is that we're not developing onl= y > for oVirt, but need to look for what makes sense for any management too= l > (or even just direct users of qemu). Indeed - that's why I still think it's dangerous to not have an atomic 'drive-reopen', even if oVirt can be coded to work in spite of an initial implementation being non-atomic. But there's a difference between wish-lists (atomic reopen) and practicality (what can we implement now), and I'm not going to insist on the impossible :) --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig91363A8330C521674A4BCD2E 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/ iQEcBAEBCAAGBQJPYJjlAAoJEKeha0olJ0NqjDsH/A/xUfKcXdW9oBtF1FyRdHe/ pNP+dZIZ/9/vRM6bdbSZPFQlpxkfmlwC6HTrIflgSkaY5JimQ5v9KINAhHg2H62t +p+BAt7T1NDKSXjpe3BALubAEBeUiZmLUQ039+sY2pjYrywWTrWqC0YA2CJFt5L8 P9/alvzdixQOuCcABTCaohh9UeoT6YKkubmIUZJSdpF8q8sDVSdjduHrjFYVqRlS 4UIaH660Xvc4X/AlNd9xDRK82OifCqoVtH2Gw0HcqioZj3ZhEMKTyQ5uvpSWjEcQ m6Q7ZasaVf1FV9CHGiA/kz7bDxAREEAXlBqAErMBtw09ngKLUlWxCzuGPfWwPm4= =RYML -----END PGP SIGNATURE----- --------------enig91363A8330C521674A4BCD2E--