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