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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list