From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpWwK-0002tV-Pi for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:43:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpWwJ-0001qc-FC for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:43:36 -0400 Date: Thu, 29 Sep 2016 16:43:25 +0800 From: Fam Zheng Message-ID: <20160929084325.GA1118@lemon> References: <20160929083435.GE5312@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160929083435.GE5312@redhat.com> Subject: Re: [Qemu-devel] RFC: handling image options with drive-mirror/drive-backup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, kwolf@redhat.com, Stefan Hajnoczi , qemu-block@nongnu.org On Thu, 09/29 09:34, Daniel P. Berrange wrote: > I got a report that the LUKS block driver was not working in combination > with the drive-mirror command and have been investigating possible fixes > for this. > > The core problem here is dealing with the target image. If you try to > run with a pre-created target that is a LUKS image, it will fail because > we have no way to provide the "key-secret" option required to open the > target. If you try to tell drive-mirror to create a new target with > LUKS format, it will fail trying to create the image, again because > no "key-secret" option can be provided. > > While this is a fundamental blocker problem for LUKS, it also affects > other image formats. For example, if you're telling drive-mirror to > create a new qcow2 volume, its impossible to control desirable attributes > like cluster-size, or compat-level. If you're mirroring a qcow2 file to > a new qcow2 file, it is impossible to maintain any custom runtimes opts > yuou might have set on the source - eg 'lazy-refcounts', or the various > discard settings will all be stuck on defaults for the target. > > You can workaround the problem of being able to create new volumes by > just creating them using qemu-img ahead of time instead. > > Dealing with the problem of opening images, requires that we have some > way to provide block options to the drive-mirror command. The naive > approach would to just add a new parameter > > 'options': ['str'] > > but IMHO this is just perpetuating the broken design of drive-mirror. > > The core problem is that this command should not have been using a > plain target + format pair of strings in the first place. Instead it > should have had a single > > "target": "BlockdevOptions" > > So my suggestion is that we deprecate "drive-mirror" and define a fixed > command "drive-mirror-blockdev" (or "blockdev-mirror" ?) that accepts > the proper BlockdevOptions QAPI type for the target as above. Are you aware that there is already a blockdev-mirror command? Supposedly it can do what you need, together with blockdev-add once the latter is deemed ready. > > This only solves the "open an existing image" case - if we want to > have drive-mirror be able to create new images, then we need to have > a new struct "BlockdevCreateOptions", since creation options are a > superset of the "BlockdevOptions". I'm inclined to say that the > "drive-mirror" command should *not* have the ability to create new > images, as I can't see a compelling reason to overload that functionality > in the same command. Images can be created out of bound with qemu-img, and opened with blockdev-add. > > Instead we should add a "blockdev-create" QMP command for doing that > action explicitly, that apps can invoke just prior to running the > drive-mirror command. We'd also want "blockdev-delete" to allow it > to be deleted on failure. > > It looks like the same design problem of drive-mirror also applies > to drive-backup. There is also blockdev-backup already. Fam > > Co-incidentally I had already been experimenting with the creation > of a "BlockdevCreateOptions" QAPI type, in order to support the > fully-nested block device creation with 'qemu-img create'. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| >