[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] block-stream/drive-mirror and default bandwidth
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] block-stream/drive-mirror and default bandwidth |
Date: |
Tue, 17 Apr 2012 06:14:52 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
On 04/17/2012 03:20 AM, Stefan Hajnoczi wrote:
> I think it's cleanest to support block-job-set-speed even when no job
> is running. The speed will be used as the default value when a job is
> started. This poses the question of what happens if the job does not
> do throttling or cannot support the value for some reason - does
> creation fail until block-job-set-speed is set to 0 or a valid value
> again, or do we allow it but silently perform no throttling?
I'd prefer failure for any request for an out-of-range speed, and I like
the idea of always letting the user set the speed, even when a job is
not already running. Am I correct that only one job can run at a time,
and therefore, the speed can be a property associated with the
BlockDevice as a whole, rather than only a property associated with each
individual job?
Libvirt would then implement virDomainBlockPull(dom, disk, bandwidth,
flags) as a call to block-job-set-speed(bandwidth) followed by
block-stream, rather than it's current implementation of block-stream
followed by block-job-set-speed. And for the RHEL 6.2 implementation
where things were spelled block_job_set_speed, libvirt will know that
the old spelling implies that the speed has to be set second and live
with the race that it implies.
--
Eric Blake address@hidden +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature