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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 02, 2011 at 08:34:19AM -0500, Adam Litke wrote:
>From: Adam Litke <agl@xxxxxxxxxx>
>To: Zhi Yong Wu <wuzhy@xxxxxxxxxxxxxxxxxx>
>Cc: libvir-list@xxxxxxxxxx
>Subject: Re:  [RFC] block I/O throttling: how to enable in libvirt
>Message-ID: <20110902133419.GW15683@xxxxxxxxxxxxxxxxxxxxxxx>
>References: <20110901050531.GB17963@xxxxxxxxxxxxxx>
> <20110902021447.GD19143@xxxxxxxxxxxxxx>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <20110902021447.GD19143@xxxxxxxxxxxxxx>
>User-Agent: Mutt/1.5.21 (2010-09-15)
>X-Brightmail-Tracker: AAAAAA==
>X-Xagent-From: agl@xxxxxxxxxx
>X-Xagent-To: wuzhy@xxxxxxxxxxxxxxxxxx
>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@xxxxxxxxxx>
>IBM Linux Technology Center

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]