From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org, kvm@vger.kernel.org
Cc: kwolf@redhat.com, aliguori@us.ibm.com,
herbert@gondor.apana.org.au, guijianfeng@cn.fujitsu.com,
wuzhy@cn.ibm.com, luowenj@cn.ibm.com, zhanx@cn.ibm.com,
zhaoyang@cn.ibm.com, llim@redhat.com, raharper@us.ibm.com,
vgoyal@redhat.com, stefanha@linux.vnet.ibm.com
Subject: [Qemu-devel] [RFC]QEMU disk I/O limits
Date: Mon, 30 May 2011 13:09:23 +0800 [thread overview]
Message-ID: <20110530050923.GF18832@f12.cn.ibm.com> (raw)
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.
More detail is available here:
http://wiki.qemu.org/Features/DiskIOLimits
1.) Why we need per-drive disk I/O limits
As you've known, for linux, cgroup blkio-controller has supported I/O throttling on block devices. More importantly, there is no single mechanism for disk I/O throttling across all underlying storage types (image file, LVM, NFS, Ceph) and for some types there is no way to throttle at all.
Disk I/O limits feature introduces QEMU block layer I/O limits together with command-line and QMP interfaces for configuring limits. This allows I/O limits to be imposed across all underlying storage types using a single interface.
2.) How disk I/O limits will be implemented
QEMU block layer will introduce a per-drive disk I/O request queue for those disks whose "disk I/O limits" feature is enabled. It can control disk I/O limits individually for each disk when multiple disks are attached to a VM, and enable use cases like unlimited local disk access but shared storage access with limits.
In mutliple I/O threads scenario, when an application in a VM issues a block I/O request, this request will be intercepted by QEMU block layer, then it will calculate disk runtime I/O rate and determine if it has go beyond its limits. If yes, this I/O request will enqueue to that introduced queue; otherwise it will be serviced.
3.) How the users enable and play with it
QEMU -drive option will be extended so that disk I/O limits can be specified on its command line, such as -drive [iops=xxx,][throughput=xxx] or -drive [iops_rd=xxx,][iops_wr=xxx,][throughput=xxx] etc. When this argument is specified, it means that "disk I/O limits" feature is enabled for this drive disk.
The feature will also provide users with the ability to change per-drive disk I/O limits at runtime using QMP commands.
Regards,
Zhiyong Wu
next reply other threads:[~2011-05-30 5:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-30 5:09 Zhi Yong Wu [this message]
2011-05-31 13:45 ` [Qemu-devel] [RFC]QEMU disk I/O limits Vivek Goyal
2011-05-31 13:50 ` Anthony Liguori
2011-05-31 14:04 ` Vivek Goyal
2011-05-31 14:25 ` Anthony Liguori
2011-05-31 17:59 ` Vivek Goyal
2011-05-31 18:39 ` Anthony Liguori
2011-05-31 19:24 ` Vivek Goyal
2011-05-31 23:30 ` Anthony Liguori
2011-06-01 13:20 ` Vivek Goyal
2011-06-01 21:15 ` Stefan Hajnoczi
2011-06-01 21:42 ` Vivek Goyal
2011-06-01 22:28 ` Stefan Hajnoczi
2011-06-04 8:54 ` Blue Swirl
2011-05-31 20:48 ` Mike Snitzer
2011-05-31 22:22 ` Anthony Liguori
2011-05-31 13:56 ` Daniel P. Berrange
2011-05-31 14:10 ` Vivek Goyal
2011-05-31 14:19 ` Daniel P. Berrange
2011-05-31 14:28 ` Vivek Goyal
2011-05-31 15:28 ` Ryan Harper
2011-05-31 19:55 ` Vivek Goyal
2011-06-01 3:12 ` Zhi Yong Wu
2011-06-02 9:33 ` Michal Suchanek
2011-06-03 6:56 ` Zhi Yong Wu
2011-06-01 3:19 ` Zhi Yong Wu
2011-06-01 13:32 ` Vivek Goyal
2011-06-02 6:07 ` Zhi Yong Wu
2011-06-02 6:17 ` Sasha Levin
2011-06-02 6:29 ` Zhi Yong Wu
2011-06-02 7:15 ` Sasha Levin
2011-06-02 8:18 ` Zhi Yong Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110530050923.GF18832@f12.cn.ibm.com \
--to=wuzhy@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=herbert@gondor.apana.org.au \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=llim@redhat.com \
--cc=luowenj@cn.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=raharper@us.ibm.com \
--cc=stefanha@linux.vnet.ibm.com \
--cc=vgoyal@redhat.com \
--cc=wuzhy@cn.ibm.com \
--cc=zhanx@cn.ibm.com \
--cc=zhaoyang@cn.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).