From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkyBX-0005bn-3P for qemu-devel@nongnu.org; Thu, 15 May 2014 12:07:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkyBS-0002uW-2U for qemu-devel@nongnu.org; Thu, 15 May 2014 12:07:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkyBR-0002uS-RN for qemu-devel@nongnu.org; Thu, 15 May 2014 12:07:02 -0400 Message-ID: <5374E622.4000805@redhat.com> Date: Thu, 15 May 2014 10:06:58 -0600 From: Eric Blake MIME-Version: 1.0 References: <50765faa0041d43d22dd14a0128d3b55850571ac.1400123059.git.jcody@redhat.com> In-Reply-To: <50765faa0041d43d22dd14a0128d3b55850571ac.1400123059.git.jcody@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PQpWFqKuvcT76WRb5m51thxEm1hI2MvRn" Subject: Re: [Qemu-devel] [PATCH 5/5] block: extend block-commit to accept a string for the backing file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody , qemu-devel@nongnu.org Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com, famz@redhat.com, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PQpWFqKuvcT76WRb5m51thxEm1hI2MvRn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/14/2014 09:20 PM, Jeff Cody wrote: > On some image chains, QEMU may not always be able to resolve the > filenames properly, when updating the backing file of an image > after a block commit. Do we want to allow qemu to error out in situations where it might get things wrong (such as if a gluster protocol is backed by a local filename) - and mandate that the user supply a backing string in those situations? But this patch is a strict improvement even if you don't go that far, because it gives libvirt the flexibility to shift the burden of name generation up the stack rather than sticking qemu with that task.= Hmm - how will this be discoverable by libvirt? Maybe when libvirt is doing the 'qemu -m none' probing, it can hotplug a device pointing to /dev/null (libvirt _already_ does that to test if add-fd works), and intentionally omit a node name. If libvirt then queries the device, and sees that the __qemu##000NNNN node-name was auto-assigned, then it can be assumed that this qemu is new enough to provide node-names for ALL operations (but that means this series is incomplete unless we add node-name support to all remaining block commands, such as block-stream, drive-mirror, and drive-backup). This part is where I wonder if patch 1/5 should be rebased to be last in the series. >=20 > For instance, certain relative pathnames may fail, or drives may > have been specified originally by file descriptor (e.g. /dev/fd/???), I'd document this as /dev/fdset/???, which is the magic string QMP uses with its add-fd command (/dev/fd/??? is platform-specific whether it will work, /dev/fdset/??? is guaranteed to work in all builds of qemu). > or a relative protocol pathname may have been used. >=20 > In these instances, QEMU may lack the information to be able to make > the correct choice, but the user or management layer most likely does > have that knowledge. >=20 > With this extension to the block-commit api, the user is able to change= > the backing file of the overlay image as part of the block-commit > operation. >=20 > This allows the change to be 'safe', in the sense that if the attempt > to write the overlay image metadata fails, then the block-commit > operation returns failure, without disrupting the guest. >=20 > If the commit top is the active layer, then specifying the backing > file string will be treated as an error (there is no overlay image > to modify in that case). >=20 > If a backing file string is not specified in the command, the backing > file string to use is determined in the same manner as it was > previously. In short, this new command option allows the equivalent of 'qemu-img rebase -u' on a live image. Definitely a needed functionality. >=20 > Signed-off-by: Jeff Cody > --- > block.c | 8 ++++++-- > block/commit.c | 9 ++++++--- > blockdev.c | 8 +++++++- > include/block/block.h | 3 ++- > include/block/block_int.h | 3 ++- > qapi-schema.json | 18 ++++++++++++++++-- > qmp-commands.hx | 14 +++++++++++++- > 7 files changed, 52 insertions(+), 11 deletions(-) >=20 > } else { > commit_start(bs, base_bs, top_bs, speed, on_error, block_job_c= b, bs, > - &local_err); > + backing_file, &local_err); See the rest of the thread about using 'has_backing_file ? backing_file : NULL' here, > +# @backing-file: #optional The backing file string to write into the o= verlay > +# image of 'top'. If 'top' is the active lay= er, > +# specifying a backing file string is an erro= r. This > +# backing file string is only written into th= e the > +# image file metadata - internal structures i= nside > +# QEMU are not updated, and the string is no= t validated. > +# If not specified, QEMU will automatically d= etermine > +# the backing file string to use. Care shoul= d be taken Maybe "If not specified, QEMU will automatically determine a backing file string to use, or error out if there is no obvious choice", to allow us flexibility in erroring out on corner cases such as mixing gluster with local files. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --PQpWFqKuvcT76WRb5m51thxEm1hI2MvRn 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTdOYiAAoJEKeha0olJ0NqIdoH/2x2IGbGd4ECHgmW334tROQq dj+yr4MhcV2HQAG0Nk5krBQepxWZne310YuJT0fHPHMUiFyfuyenMaBHBp80oE2y Z4+Lbbu6lYZYXFnNXBeUNuqEyP4TcEfmAqBAu9L3iaP3pLx2vS/9u5nMA31PDTW2 3+S95E0i+hrRoT0m6A+B3SYyxYjt7YRHqlrrcQ89EM9otEmUnBs6UGBTFYBo+6Nj dBbmhVL8ElayIGGmFem4bz4PQuFBGVTrhzI1j0qaaF7oThErE51eg+xbRJYIAxS2 ND6bXuKMy68zNqZ5ccoynn1xKIqP6iqv9sz370uU0CJZLn2+kxuO/o9rhcubD/w= =2ci6 -----END PGP SIGNATURE----- --PQpWFqKuvcT76WRb5m51thxEm1hI2MvRn--