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

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(a)us.ibm.com&gt; 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-i... > >> > >> 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.