On 04/17/2012 02:32 AM, Jiri Denemark wrote:
> In the meantime, I think I will patch this instead by
documentation:
> state that non-zero bandwidth in virDomainBlockRebase() may be silently
> ignored; if error checking is needed, the user should use a separate
> call to virDomainBlockJobSetSpeed(); and to see if a request was
> honored, use virDomainGetBlockJobInfo() (with the known race that the
> job might already be complete).
Makes sense, although we don't want to store the result of
BLOCK_JOB_SPEED_INTERNAL to be stored in ret, then.
Actually, qemu may save us - they are agreeing that this is a problem,
and will probably have a patch before libvirt 0.9.12 that allows
block-job-set-speed to be called prior to block-stream or drive-mirror;
at which point the correct fix is to then try to set the speed _prior_
to starting the job (but only when we know we are talking to qemu 1.1,
not RHEL 6.2). It would leave RHEL 6.2 with the race, but oh well.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org