On Thu, Sep 01, 2011 at 01:05:31PM +0800, Zhi Yong Wu wrote:
On Wed, Aug 31, 2011 at 08:18:19AM +0100, Stefan Hajnoczi wrote:
>On Tue, Aug 30, 2011 at 2:46 PM, Adam Litke <agl(a)us.ibm.com> wrote:
>> On Tue, Aug 30, 2011 at 09:53:33AM +0100, Stefan Hajnoczi wrote:
>>> I/O throttling can be applied independently to each -drive attached to
>>> a guest and supports throughput/iops limits. For more information on
>>> this QEMU feature and a comparison with blkio-controller, see Ryan
>>> Harper's KVM Forum 2011 presentation:
>>
>>>
http://www.linux-kvm.org/wiki/images/7/72/2011-forum-keep-a-limit-on-it-i...
>>
>> From the presentation, it seems that both the cgroups method the the qemu
method
>> offer comparable control (assuming a block device) so it might possible to
apply
>> either method from the same API in a transparent manner. Am I correct or are
we
>> suggesting that the Qemu throttling approach should always be used for Qemu
>> domains?
>
>QEMU I/O throttling does not provide a proportional share mechanism.
>So you cannot assign weights to VMs and let them receive a fraction of
>the available disk time. That is only supported by cgroups
>blkio-controller because it requires a global view which QEMU does not
>have.
>
>So I think the two are complementary:
>
>If proportional share should be used on a host block device, use
>cgroups blkio-controller.
>Otherwise use QEMU I/O throttling.
Stefan,
Do you agree with introducing one new libvirt command blkiothrottle now?
If so, i will work on the code draft to make it work.
No, I think that the blkiotune command should be extended to support
QEMU I/O throttling. This is not new functionality, we already have
cgroups blkio-controller support today. Therefore I think it makes
sense to keep a unified interface instead of adding a new command.
Stefan