Re: [Qemu-devel] RFC: handling image options with drive-mirror/drive-backup

[Kevin Wolf <kwolf@redhat.com>]

Am 29.09.2016 um 11:43 hat Daniel P. Berrange geschrieben:
> On Thu, Sep 29, 2016 at 11:17:52AM +0200, Kevin Wolf wrote:
> > Am 29.09.2016 um 11:09 hat Fam Zheng geschrieben:
> > > On Thu, 09/29 09:51, Daniel P. Berrange wrote:
> > > > On Thu, Sep 29, 2016 at 04:43:25PM +0800, Fam Zheng wrote:
> > > > > On Thu, 09/29 09:34, Daniel P. Berrange wrote:
> > > > > > 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.
> > > > 
> > > > Clearly I'm not aware of that :-)  It seems libvirt does not yet use
> > > > blockdev-mirror either, which is where I got the original bug report
> > > > about drive-mirror from.
> > > 
> > > Libvirt doesn't support blockdev-add yet, because the command is still being
> > > actively worked on at QEMU side, and is therefore thought to be not "stable"
> > > yet. Though, I think blockdev-add + blockdev-{mirror,backup} are already useful
> > > for common tasks (like your use case with LUKS).
> > 
> > Just to clarify what "not stable" means: Literally none of the
> > blockdev-add commands that used to work when it was originally merged
> > are still working. And we're considering another similar change
> > (removing the "options" indirection) that will change the command for
> > all users. So while I would encourage libvirt to write prototyp code for
> > supporting blockdev-add now, I would advise against enabling it in a
> > release yet.
> 
> Urgh, arbitrarily changing behaviour of existing commands is really
> very bad for libvirt, as it means we have to now write special case
> logic to detect whether we can use the command or not, instead of
> merely detecting whether it exists.
> 
> If commands are expected to change, they should have an 'x-' prefix
> and once that's removed they should never be changed in an incompatible
> manner again.

Yes, we messed up this one. Don't use blockdev-add until x-blockdev-del
has been renamed.

Kevin