[libvirt] [PATCH 0/8 v5] Summary on block IO throttle

[Stefan Hajnoczi]

On Wed, Jan 18, 2012 at 09:22:01AM -0700, Eric Blake wrote:
> On 11/23/2011 02:18 AM, Stefan Hajnoczi wrote:
> >>>> Notes: Now all the planed features were implemented (#1#2 were implemented by
> >>>> Zhi Yong Wu), the previous comments were all fixed up too. And the qemu part patches
> >>>> have been accepted upstream and are expected to be part of the QEMU 1.1
> >>>> release, git tree from Zhi Yong:
> >>>>
> >>>> http://repo.or.cz/w/qemu/kevin.git/shortlog/refs/heads/block
> >>>
> >>> I just realized that the block_set_io_throttle monitor command is not
> >>> yet in released upstream qemu.  I will continue reviewing this series,
> >>> but it's harder to justify including it into libvirt 0.9.8 unless we
> >>> have a good feel that the design for qemu is stable and unlikely to
> >> I strongly think that the syntax of this qemu monitor command will be
> >> not changed later. :)
> >> Moreover, it has not been changed since the patches for qemu block I/O
> >> throttling is published.
> > 
> > It's good to be careful about adding libvirt features that are not yet
> > in QEMU.  I got burnt by this with image streaming and have had to
> > work extra hard to finally get the QEMU side merged with the libvirt
> > side already set in stone.
> > 
> > However, Kevin has merged the QEMU I/O throttling patches into the
> > block tree.  They are waiting for the 1.1 merge window because
> > qemu.git has only been taking QEMU 1.0-rc patches for the past few
> > weeks.  QEMU I/O throttling has been through review and accepted by
> > the community:
> > 
> > http://patchwork.ozlabs.org/patch/124266/
> 
> How can libvirt reliably tell whether block throttling is supported?
> Does that patch series alter the help output of 'qemu -h' to list
> something like '-drive ...[,bps=...]'?  Is there a magic 'qemu -driver
> xxx,?' call where we can see that the new bps attribute is settable?
> 
> I ask, because we need to alter libvirt to properly detect whether qemu
> supports this new feature, so as to gracefully reject attempts to use
> the XML if qemu does not support the feature.  See also:
> https://www.redhat.com/archives/libvir-list/2012-January/msg00727.html

The most robust method is to use QMP query-commands or HMP help to look
for the block I/O throttling commands.

Scraping qemu -h is possible too but fragile, note the last line of help
output:

-drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]
       [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]
       [,cache=writethrough|writeback|none|directsync|unsafe][,format=f]
       [,serial=s][,addr=A][,id=name][,aio=threads|native]
       [,readonly=on|off][,copy-on-read=on|off]
       [[,bps=b]|[[,bps_rd=r][,bps_wr=w]]][[,iops=i]|[[,iops_rd=r][,iops_wr=w]]

Here's a hack that really probes.  Block I/O throttling supported:

$ qemu-system-x86_64 -drive bps=1,bps_rd=1
qemu-system-x86_64: -drive bps=1,bps_rd=1: bps(iops) and bps_rd/bps_wr(iops_rd/iops_wr) cannot be used at the same time

Block I/O throttling *not* supported:

$ qemu-system-x86_64 -drive bps=1,bps_rd=1
qemu-system-x86_64: -drive bps=1,bps_rd=1: Invalid parameter 'bps'

Stefan