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

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Sep 01, 2011 at 09:11:49AM +0100, Stefan Hajnoczi wrote:
> 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@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.

Agreed, the virDomainGetBlkioParameters/virDomainSetBlkioParameters
APIs, and blkio virsh command are intended to be a generic interface
for setting any block related tuning parameters, regardless of what
the underling implementation is. So any use of QEMU I/O throttling
features should be added to those APIs/commands.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|