[libvirt] [RFC] block I/O throttling: how to enable in libvirt

[Zhi Yong Wu]

On Fri, Sep 02, 2011 at 08:34:19AM -0500, Adam Litke wrote:
>From: Adam Litke <agl at us.ibm.com>
>To: Zhi Yong Wu <wuzhy at linux.vnet.ibm.com>
>Cc: libvir-list at redhat.com
>Subject: Re: [libvirt] [RFC] block I/O throttling: how to enable in libvirt
>Message-ID: <20110902133419.GW15683 at aglitke.rchland.ibm.com>
>References: <20110901050531.GB17963 at f15.cn.ibm.com>
> <20110902021447.GD19143 at f15.cn.ibm.com>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <20110902021447.GD19143 at f15.cn.ibm.com>
>User-Agent: Mutt/1.5.21 (2010-09-15)
>X-Brightmail-Tracker: AAAAAA==
>X-Xagent-From: agl at us.ibm.com
>X-Xagent-To: wuzhy at linux.vnet.ibm.com
>X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGENTU8 at VMSDVMA)
>
>On Fri, Sep 02, 2011 at 10:14:48AM +0800, Zhi Yong Wu wrote:
>> On Thu, Sep 01, 2011 at 01:05:31PM +0800, Zhi Yong Wu wrote:
>> HI, Adam,
>> Now stefan, Daniel, and Gui all suggest extending blkiotune to keep libivrt unified interface. What do you think of it?
>
>It seems like it would be nice to extend the blkiotune API for this use case,
>but there is one problem.  The blkiotune interface operates at the VM level and
>the QEMU throttling is at the disk level.  So if you want per-disk throttling
>granularity the blkiotune API may not be suitable.  I see 3 possible paths
>forward:
>
>1) Accept the blkiotune limitation of a global setting and add a throttle option
>that assigns the same throttle value to all disks.
>
>  <blkiotune>
>    <shares>250</shares>
>    <throttle>1024</throttle>
>  </blkiotune>
>
>  + Nice for simplicity and ease of implementation
>  - May be too simplistic (can't set different throttling for different disks)
>
>
>2) Extend the blkiotune API to allow per-disk tunings:
>
>  <blkiotune>
>    <shares>250</shares>
>    <throttle device='virtio-disk0'>1024</throttle>
>  </blkiotune>
>
>  + Use an existing API
>  - Unfortunately it doesn't look like this can be done cleanly
>
>
>3) Use a new API virDomainSetBlkDevParameters() to set device specific
>tuning parameters:
>
><blkiotune>
>  <shares>250</shares>
></blkiotune>
>...
><disk type='file' device='disk'>
>  <driver name='qemu' type='raw'/>
>  <source file='...'/>
>  <target dev='vda' bus='virtio'/>
>  <blkdevtune>
>    <throttle>1024</throttle>
Several I/O throttling tags should be supported, such as thrbps, thrbpsrd, thrbpswr, thriops, etc.
>  </blkdevtune>
></disk>
>
>  + Throttle can be specified with the disk it is effecting
>  - Proliferation of tuning APIs
>
>
>Obviously #1 is the best if you can accept the limitations of the API.  #2 would
#1 is not accepted by us. If it is adopted, the advantage of QEMU I/O throttling is not used fully.
>be nice if we could figure out how to extend virTypedParameter to represent a
I guess that #2 is less extendable than #3.
>(disk, param) pair.  I see #3 as a last resort.  Did I miss any other solutions.
To be honest, i prefer to #3. At first, i plan to check how blkiotune works currently.
>Did I just manage to completely over-complicate this? :)
NO, they are nice. thanks.


Regards,

Zhiyong Wu
>
>-- 
>Adam Litke <agl at us.ibm.com>
>IBM Linux Technology Center