From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5ZLf-0000sZ-Ji for qemu-devel@nongnu.org; Thu, 18 Jun 2015 08:55:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5ZLe-0000z2-GW for qemu-devel@nongnu.org; Thu, 18 Jun 2015 08:55:15 -0400 Message-ID: <5582BFA4.8090400@redhat.com> Date: Thu, 18 Jun 2015 06:55:00 -0600 From: Eric Blake MIME-Version: 1.0 References: <20150616085102.GA22306@perseus.local> <20150618104535.GD4270@noname.redhat.com> <20150618114720.GE4270@noname.redhat.com> <5582BB3D.8050608@redhat.com> In-Reply-To: <5582BB3D.8050608@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UJfqVtdemknx61Nf684fOudaXjE5jTQu6" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v7 00/11] Support streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , Kevin Wolf Cc: qemu-block@nongnu.org, "libvir-list@redhat.com" , armbru@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UJfqVtdemknx61Nf684fOudaXjE5jTQu6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [adding libvirt, to make sure I capture a design idea] On 06/18/2015 06:36 AM, Eric Blake wrote: > On 06/18/2015 06:07 AM, Alberto Garcia wrote: >> On Thu 18 Jun 2015 01:47:20 PM CEST, Kevin Wolf wrote: >> >>>>> I believe our conclusion from an earlier version of the series was >>>>> that we need QAPI introspection so that libvirt can detect the >>>>> presence of the feature. >=20 > Detecting the presence of a feature allows libvirt the luxury of giving= > its own error message, rather than relying on the qemu message. But > that's not to say libvirt HAS to use its own error message, and > therefore being unable to detect the feature may not be the end of the > world. >=20 >> That said, I would prefer a way to detect the feature that does not >> involve testing commands for their error codes, but is there any? What= >> does libvirt generally do in order to detect new features that don't >> depend on API changes? >=20 > But libvirt has not yet set up node name management (I'm about to reviv= e > Jeff's patch for auto-node-naming simultaneously with a libvirt patch > series that proves that it helps libvirt), and libvirt will need a new > API to allow users a way to request streams to an intermediate image. > So anything libvirt does to interact with the new stream-to-intermediat= e > will have to be new code, and I can worry about whether the qemu error > message is good enough, or whether I have to contrive some probing test= > to see if it even works; but my initial thought is that merely probing > to see if auto-node-naming is in place is a good approximation filter > (if libvirt isn't managing its own node names, then the only way to use= > stream-to-intermediate is via a node name automatically supplied by > qemu, especially nice if both features land in 2.4). Actually, in thinking more about it, libvirt won't need a new API; the existing virDomainBlockPull() and virDomainBlockRebase() are sufficient, if I allow libvirt to treat "vda[1]" as a destination (which is the first backing image of disk vda; pretty much similar to how qemu is adding node names rather than device names as a way to make the existing block-stream now stream to intermediate). And that is consistent with the way we have been retrofitting other existing libvirt API to refer to specific backing images. On libvirt's front, I may want to add a new flag (where the flag must be present to make it clear that stream-to-intermediate is desired, so that upper level applications can use the absence of the libvirt flag as their feature probe), but that has no bearing on what qemu has to do to turn on the feature. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --UJfqVtdemknx61Nf684fOudaXjE5jTQu6 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVgr+kAAoJEKeha0olJ0NqgucH/i05eAdSzfyua2n9piFtc4tb HuUk8bZazjQtqGy+eyFGALo82WIqPSH0DYu6GWT+lQCxqSwlpgCvRU1kQHPf6eYo cAblWpGfdtBlJEnSlCfS3lgHHH0WKDXG9GYzs9geZ+0E95sRxuv17u88I7KIDPHh SLHFOfYGWrw3RV4nBVeZWv+buwp/NDWuvmuZT4iWzNwvzNgeFICBA0prBOu2oO1h x6XKZZb0JkFw2ou5YOOwDQmQFJ5f8G+HDjHY5wmIbso4OLQ3+k8J2tMqCxK1phO9 PgKgG4+z94zFiBasz1v2pCSouowy/6r0eJ3EzMkvrn7iC0ZKqA24xqPs+IyqklQ= =h0aB -----END PGP SIGNATURE----- --UJfqVtdemknx61Nf684fOudaXjE5jTQu6--