Bug 1349898
| Summary: | Extend <iotune> for QEMU bps_max_length/iops_max_length | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Stefan Hajnoczi <stefanha> |
| Component: | libvirt | Assignee: | John Ferlan <jferlan> |
| Status: | CLOSED ERRATA | QA Contact: | yisun |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | dyuan, jdenemar, jsuchane, lmen, ngu, pzhang, rbalakri, stefanha, xuzhang, yhong |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-2.5.0-1.el7 | Doc Type: | Enhancement |
| Doc Text: |
Feature: Add duration/length options for the domain block iotune values to match the existing size and max values.
Reason: The duration/length limits provide a maximum duration in seconds for their maximum burst values.
Result: See virsh blkdeviotune man page
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 17:09:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Stefan Hajnoczi
2016-06-24 13:24:05 UTC
Started working through the basics to add support for the new options to libvirt... I tripped across an issue though due to how libvirt currently generates the qemu command line. I get the following error(s) if all I do is add support to have a {bps|iops}_*_length parameter on the command line:
... -drive file=/home/vm-images/f18,format=raw,if=none,id=drive-virtio-disk0,bps=5000,iops=6000,bps_max=10000,iops_max=11000,bps_max_length=3,iops_max_length=5: Block format 'raw' does not support the option 'iops_max_length'
... -drive file=/home/vm-images/f18,format=raw,if=none,id=drive-virtio-disk0,bps_rd=5000,bps_wr=5500,iops_rd=3500,iops_wr=4000,bps_rd_max=6000,bps_wr_max=6500,iops_rd_max=7000,iops_wr_max=7500,iops_size=2000,bps_rd_max_length=3: Block format 'raw' does not support the option 'bps_rd_max_length'
The guest I have uses a top of tree build:
/home/qemu/x86_64-softmmu/qemu-system-x86_64 --version
QEMU emulator version 2.7.50 (v2.7.0-441-gf5edc82), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
I know when I added support for luks on the command line I had to prefix the (new) password-secret argument with "file." because libvirt uses a 'legacy' syntax of "-drive file=..." instead of a newer syntax of "-drive driver=%s,filename=..."
Similarly, I tried adding "throttling.{bps|iops}-*", "file.{bps|iops}-*", and "file.throttling.{bps|iops}-*" - none worked.
Alternatively, I note that blockdev.c/drive_new() seems to have some sort of alias for the command options. If I modify that to include the _length values and rebuild, then I can successfully start my domain with the _length parameters.
+ { "iops_max_length", "throttling.iops-total-max-length" },
+ { "iops_rd_max_length", "throttling.iops-read-max-length" },
+ { "iops_wr_max_length", "throttling.iops-write-max-length" },
+
+ { "bps_max_length", "throttling.bps-total-max-length" },
+ { "bps_rd_max_length", "throttling.bps-read-max-length" },
+ { "bps_wr_max_length", "throttling.bps-write-max-length" },
+
So, does this mean libvirt is going to be "forced" to use the newer "-drive driver=%s,file=%s..." syntax? or is there some "syntax" that could work without this kind of change?
(In reply to John Ferlan from comment #2) > Started working through the basics to add support for the new options to > libvirt... I tripped across an issue though due to how libvirt currently > generates the qemu command line. I get the following error(s) if all I do > is add support to have a {bps|iops}_*_length parameter on the command line: > > ... -drive > file=/home/vm-images/f18,format=raw,if=none,id=drive-virtio-disk0,bps=5000, > iops=6000,bps_max=10000,iops_max=11000,bps_max_length=3,iops_max_length=5: > Block format 'raw' does not support the option 'iops_max_length' > > ... -drive > file=/home/vm-images/f18,format=raw,if=none,id=drive-virtio-disk0, > bps_rd=5000,bps_wr=5500,iops_rd=3500,iops_wr=4000,bps_rd_max=6000, > bps_wr_max=6500,iops_rd_max=7000,iops_wr_max=7500,iops_size=2000, > bps_rd_max_length=3: Block format 'raw' does not support the option > 'bps_rd_max_length' > > The guest I have uses a top of tree build: > > /home/qemu/x86_64-softmmu/qemu-system-x86_64 --version > QEMU emulator version 2.7.50 (v2.7.0-441-gf5edc82), Copyright (c) 2003-2016 > Fabrice Bellard and the QEMU Project developers > > I know when I added support for luks on the command line I had to prefix the > (new) password-secret argument with "file." because libvirt uses a 'legacy' > syntax of "-drive file=..." instead of a newer syntax of "-drive > driver=%s,filename=..." > > Similarly, I tried adding "throttling.{bps|iops}-*", "file.{bps|iops}-*", > and "file.throttling.{bps|iops}-*" - none worked. > > Alternatively, I note that blockdev.c/drive_new() seems to have some sort of > alias for the command options. If I modify that to include the _length > values and rebuild, then I can successfully start my domain with the _length > parameters. > > + { "iops_max_length", "throttling.iops-total-max-length" }, > + { "iops_rd_max_length", "throttling.iops-read-max-length" }, > + { "iops_wr_max_length", "throttling.iops-write-max-length" }, > + > + { "bps_max_length", "throttling.bps-total-max-length" }, > + { "bps_rd_max_length", "throttling.bps-read-max-length" }, > + { "bps_wr_max_length", "throttling.bps-write-max-length" }, > + > > So, does this mean libvirt is going to be "forced" to use the newer "-drive > driver=%s,file=%s..." syntax? or is there some "syntax" that could work > without this kind of change? There are no shortcuts for bps_max_length and iops_max_length. There are no plans to add shortcuts for advanced options AFAIK. The long form options should be used: qemu-system-x86_64 -enable-kvm -m 1024 -cpu host \ -drive if=virtio,file=test.img,format=raw,\ throttling.bps-total=N,\ throttling.bps-total-max=M,\ throttling.bps-total-max-length=L Ahh.. OK... Turns out it wasn't happy to handle intermixed alias and long hand. If I convert all the existing short hand to longer form and then add the -length parameters, things work. I've posted patches upstream: http://www.redhat.com/archives/libvir-list/2016-September/msg01090.html A v2 was posted today: http://www.redhat.com/archives/libvir-list/2016-October/msg00272.html Some patches from v1 already pushed - v2 includes some things found during debugging of setting the values from virsh (I forgot about virsh in v1). This series is finally pushed:
commit 13022ce430da9d6ce4dc9e9117d6be519e7afc4a
Author: John Ferlan <jferlan>
Date: Sun Oct 2 08:24:31 2016 -0400
virsh: Add _length parameters to virsh output
$ git describe 13022ce430da9d6ce4dc9e9117d6be519e7afc4a
v2.3.0-202-g13022ce
Verified and PASSED
versions:
libvirt-3.2.0-6.el7.x86_64
steps:
1. check blkdeviotune output when getting info
## virsh blkdeviotune r vdb
...
total_bytes_sec_max_length: 0
read_bytes_sec_max_length: 0
write_bytes_sec_max_length: 0
total_iops_sec_max_length: 0
read_iops_sec_max_length: 0
write_iops_sec_max_length: 0
2. check blkdeviotune taking effect when setting info
## virsh blkdeviotune r vdb --total-bytes-sec 111 --total-bytes-sec-max 33333 --total-bytes-sec-max-length 555
## virsh dumpxml r | grep length
<total_bytes_sec_max_length>555</total_bytes_sec_max_length>
-- restart vm --
## virsh blkdeviotune r vdb --read-bytes-sec 111 --read-bytes-sec-max 33333 --read-bytes-sec-max-length 555
## virsh dumpxml r | grep length
<read_bytes_sec_max_length>555</read_bytes_sec_max_length>
-- restart vm --
## virsh blkdeviotune r vdb --write-bytes-sec 111 --write-bytes-sec-max 33333 --write-bytes-sec-max-length 555
## virsh dumpxml r | grep length
<write_bytes_sec_max_length>555</write_bytes_sec_max_length>
-- restart vm --
## virsh blkdeviotune r vdb --total-iops-sec 111 --total-iops-sec-max 33333 --total-iops-sec-max-length 555
## virsh dumpxml r | grep length
<total_iops_sec_max_length>555</total_iops_sec_max_length>
-- restart vm --
## virsh blkdeviotune r vdb --read-iops-sec 111 --read-iops-sec-max 33333 --read-iops-sec-max-length 555
## virsh dumpxml r | grep length
<read_iops_sec_max_length>555</read_iops_sec_max_length>
-- restart vm --
## virsh blkdeviotune r vdb --write-iops-sec 111 --write-iops-sec-max 33333 --write-iops-sec-max-length 555
## virsh dumpxml r | grep length
<write_iops_sec_max_length>555</write_iops_sec_max_length>
3. check setting with --config option and check vm's qemu cmd with existing settings
## virsh blkdeviotune r vdb --total-bytes-sec 111 --total-bytes-sec-max 33333 --total-bytes-sec-max-length 555 --config
## virsh dumpxml r | grep length
<=== nothing, as expected
## virsh dumpxml r --inactive| grep length
<total_bytes_sec_max_length>555</total_bytes_sec_max_length>
<=== show up in inactive vm xml, as expected
## virsh destroy r
Domain r destroyed
## virsh start r
virsh dumDomain r started
## virsh dumpxml r | grep length
<total_bytes_sec_max_length>555</total_bytes_sec_max_length>
## ps -ef | grep qemu | grep 555
qemu 6685 1 43 14:59 ? 00:00:16 /usr/libexec/qemu-kvm -name guest=r,...-drive file=/var/lib/libvirt/images/luks.disk,key-secret=virtio-disk1-luks-secret0,format=luks,if=none,id=drive-virtio-disk1,throttling.bps-total=111,throttling.bps-total-max=33333,throttling.bps-total-max-length=555 ...
... and this works for other parameters
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1846 |