From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [RFC]QEMU disk I/O limits Date: Tue, 31 May 2011 09:25:31 -0500 Message-ID: <4DE4FA5B.1090804@codemonkey.ws> References: <20110530050923.GF18832@f12.cn.ibm.com> <20110531134537.GE16382@redhat.com> <4DE4F230.2040203@us.ibm.com> <20110531140402.GF16382@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, guijianfeng@cn.fujitsu.com, qemu-devel@nongnu.org, wuzhy@cn.ibm.com, herbert@gondor.hengli.com.au, Zhi Yong Wu , luowenj@cn.ibm.com, zhanx@cn.ibm.com, zhaoyang@cn.ibm.com, llim@redhat.com, Ryan A Harper To: Vivek Goyal Return-path: Received: from mail-yi0-f46.google.com ([209.85.218.46]:59008 "EHLO mail-yi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750830Ab1EaOZd (ORCPT ); Tue, 31 May 2011 10:25:33 -0400 Received: by yia27 with SMTP id 27so1779083yia.19 for ; Tue, 31 May 2011 07:25:33 -0700 (PDT) In-Reply-To: <20110531140402.GF16382@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/31/2011 09:04 AM, Vivek Goyal wrote: > On Tue, May 31, 2011 at 08:50:40AM -0500, Anthony Liguori wrote: >> On 05/31/2011 08:45 AM, Vivek Goyal wrote: >>> On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: >>>> Hello, all, >>>> >>>> I have prepared to work on a feature called "Disk I/O limits" for qemu-kvm projeect. >>>> This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. >>>> >>> >>> Hi Zhiyong, >>> >>> Why not use kernel blkio controller for this and why reinvent the wheel >>> and implement the feature again in qemu? >> >> blkio controller only works for block devices. It doesn't work when >> using files. > > So can't we comeup with something to easily determine which device backs > up this file? Though that will still not work for NFS backed storage > though. Right. Additionally, in QEMU, we can rate limit based on concepts that make sense to a guest. We can limit the actual I/O ops visible to the guest which means that we'll get consistent performance regardless of whether the backing file is qcow2, raw, LVM, or raw over NFS. The kernel just doesn't have enough information to do a good job here. Regards, Anthony Liguori > > Thanks > Vivek >