[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] RFC: handling image options with drive-mir
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [Qemu-devel] RFC: handling image options with drive-mirror/drive-backup |
Date: |
Thu, 29 Sep 2016 12:37:21 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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