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

[Stefan Hajnoczi]

On Fri, Sep 2, 2011 at 3:09 AM, Zhi Yong Wu <wuzhy at linux.vnet.ibm.com> wrote:
> On Thu, Sep 01, 2011 at 09:11:49AM +0100, Stefan Hajnoczi wrote:
>>Date: Thu, 1 Sep 2011 09:11:49 +0100
>>From: Stefan Hajnoczi <stefanha at gmail.com>
>>To: Zhi Yong Wu <wuzhy at linux.vnet.ibm.com>
>>Message-ID: <20110901081149.GB14245 at stefanha-thinkpad.localdomain>
>>References: <20110901050531.GB17963 at f15.cn.ibm.com>
>>MIME-Version: 1.0
>>Content-Type: text/plain; charset=iso-8859-1
>>Content-Disposition: inline
>>Content-Transfer-Encoding: 8bit
>>In-Reply-To: <20110901050531.GB17963 at f15.cn.ibm.com>
>>User-Agent: Mutt/1.5.21 (2010-09-15)
>>X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2)
>>X-Received-From: 74.125.82.173
>>Cc: libvir-list at redhat.com, guijianfeng at cn.fujitsu.com, agl at us.ibm.com,
>> qemu-devel at nongnu.org, zwu.kernel at gmail.com, hutao at cn.fujitsu.com
>>Subject: Re: [Qemu-devel] [RFC] block I/O throttling: how to enable in
>>       libvirt
>>X-BeenThere: qemu-devel at nongnu.org
>>X-Mailman-Version: 2.1.14
>>Precedence: list
>>List-Id: <qemu-devel.nongnu.org>
>>List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
>> <mailto:qemu-devel-request at nongnu.org?subject=unsubscribe>
>>List-Archive: </archive/html/qemu-devel>
>>List-Post: <mailto:qemu-devel at nongnu.org>
>>List-Help: <mailto:qemu-devel-request at nongnu.org?subject=help>
>>List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
>> <mailto:qemu-devel-request at nongnu.org?subject=subscribe>
>>X-Mailman-Copy: yes
>>Errors-To: qemu-devel-bounces+wuzhy=linux.vnet.ibm.com at nongnu.org
>>Sender: qemu-devel-bounces+wuzhy=linux.vnet.ibm.com at nongnu.org
>>x-cbid: 11090108-7282-0000-0000-0000010970B0
>>X-IBM-ISS-SpamDetectors: Score=0; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0;
>> SC=0; ST=0; TS=0; UL=0; ISC=
>>X-IBM-ISS-DetailInfo: BY=3.00000211; HX=3.00000168; KW=3.00000007;
>> PH=3.00000001; SC=3.00000001; SDB=6.00067104; UDB=6.00020326;
>> UTC=2011-09-01 08:12:15
>>X-Xagent-From: stefanha at gmail.com
>>X-Xagent-To: wuzhy at linux.vnet.ibm.com
>>X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGENTU5 at VMSDVM6)
>>
>>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 at 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-io-throttling-in-qemu.pdf
>>> >>
>>> >> 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.
> QEMU I/O throttling currently don't support those options of blkiotune, such as --live, --config and --current.If those bps/iops settings are modified, it will immediately take effect.

The --live, --config, and --current options are implemented inside
libvirt and do not require hypervisor support.  Take a look at
src/qemu/qemu_driver.c:qemuDomainSetBlkioParameters() to see how these
options are implemented for blkiotune today.

Stefan