Description of problem: there are some logic issues for blkdeviotune Version-Release number of selected component (if applicable): libvirt-2.0.0-9.el7.x86_64 qemu-kvm-rhev-2.6.0-25.el7.x86_64 How reproducible: 100% Steps to Reproduce: I have arranged the logic for blkdeviotune,and have confirmed it with qemu qe. So I think there are some logic issues in libvirt. logic1：the value of total_bytes_sec and total_bytes_sec_max can't be set **one by one**,so the scenario1 below is right,and scenario 2 below is wrong. scenario 1: when total_bytes_sec and total_bytes_sec_max are both 0,set total-bytes-sec-max as 10. [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 0 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 [root@localhost ~]# virsh blkdeviotune bios hda --total-bytes-sec-max 10 error: Unable to change block I/O throttle error: unsupported configuration: value 'total_bytes_sec_max' cannot be set if 'total_bytes_sec' is not set scenario2: set total-bytes-sec as 1000,and total-bytes-sec-max as 2000（more than total-bytes-sec） [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 0 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 [root@localhost ~]# virsh blkdeviotune bios hda --total-bytes-sec 1000 [root@localhost ~]# virsh blkdeviotune bios hda --total-bytes-sec-max 2000 （-->more than total-bytes-sec） [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 1000 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 2000 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 logic2： the value of total_bytes_sec and total_bytes_sec_max can be set ***at the same time***, but the value of total_bytes_sec_max can't be less than total_bytes_sec.The scenario 3 below is not accurate.The scenario is being tracked in bug 1344897. scenario3: [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 0 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 [root@localhost ~]# virsh blkdeviotune bios hda --total-bytes-sec 1000 --total-bytes-sec-max 500 error: Unable to change block I/O throttle error: internal error: Unexpected error logic3： for the following parameter，total and read/write cannot be set at the same time.but read and write can be set at the same time parameter: total_bytes_sec read_bytes_sec write_bytes_sec In libvirt,the logic is right. logic4： for the following parameter，they can be set one by one. but after setting one parameter ,the value of other parameters will be set as 0 automatically. the scenario 4 below is right,but scenario 5 blow is wrong. parameter: total_bytes_sec read_bytes_sec write_bytes_sec total_iops_sec read_iops_sec write_iops_sec scenario4: [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 0 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 [root@localhost ~]# virsh blkdeviotune bios hda --read-bytes-sec 100 [root@localhost ~]# virsh blkdeviotune bios hda --write-bytes-sec 200 [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 0 read_bytes_sec : 0 -->it is set as 0 automatically. write_bytes_sec: 200 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 20 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 scenario 5: [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 0 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 [root@localhost ~]# virsh blkdeviotune bios hda --total-bytes-sec 200 [root@localhost ~]# virsh blkdeviotune bios hda --total-iops-sec 300 [root@localhost ~]# virsh blkdeviotune bios hda total_bytes_sec: 200 --->it should be set as 0 automatically. read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 300 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 20 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 30 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 So I think,scenario 2 and scenario 5 should be fixed in this bug. Am I right? Actual results: Expected results: Additional info:
I don't see any problem with scenario 2, _max must be either 0 (not set) or greater than or equal to it's counterpart. I see problem with scenario 4, read and write should be able to be set together. Ad scenario 5, I don't see why iops and bytes couldn't be set at the same time. How did you manage to set iops_sec_max to less than iops_sec (as seen in scenarios 4 and 5 as a side effect)?
(In reply to Martin Kletzander from comment #2) > I don't see any problem with scenario 2, _max must be either 0 (not set) or > greater than or equal to it's counterpart. I see problem with scenario 4, > read and write should be able to be set together. Ad scenario 5, I don't > see why iops and bytes couldn't be set at the same time. How did you manage > to set iops_sec_max to less than iops_sec (as seen in scenarios 4 and 5 as a > side effect)? HI Martin, I am a kvm qe. Let's check the problem one by one. For scenario 2, the problem is the same as scenario 5, i.e. if you want to use 2 or multi values, you should specify them together instead of one by one. The counterpart of scenario 5 in qemu side is as following qmp cmds: { "execute": "block_set_io_throttle", "arguments": { "device": "drive_stg0","bps": 200,"bps_rd": 0,"bps_wr": 0,"iops": 0,"iops_rd": 0,"iops_wr": 0 } } ####After the 1st cmd, the total-bytes-sec(bps) is 200, while total-iops-sec(iops) is 0 { "execute": "block_set_io_throttle", "arguments": { "device": "drive_stg0","bps": 0,"bps_rd": 0,"bps_wr": 0,"iops": 300,"iops_rd": 0,"iops_wr": 0 } } ####After the 2nd cmd, the total-bytes-sec is 0, while total-iops-sec is 300; if you want to set both of them, you should set them together as follows { "execute": "block_set_io_throttle", "arguments": { "device": "drive_stg0","bps": 200,"bps_rd": 0,"bps_wr": 0,"iops": 300,"iops_rd": 0,"iops_wr": 0 } } ####After the 3rd cmd, bps is 200 while iops is 300 now So for scenario 4, there is no problem, it's the right behaviour. For scenario 3, compared with scenario 2, the problem is that the error prompt is wrong when "total-bytes-sec-max" is less than "total-bytes-sec"; in qemu side, the error prompt is "bps_max/iops_max cannot be lower than bps/iops". Also cc the corresponding kvm developer stefanha
(In reply to Martin Kletzander from comment #2) > I don't see any problem with scenario 2, _max must be either 0 (not set) or > greater than or equal to it's counterpart. I see problem with scenario 4, > read and write should be able to be set together. Ad scenario 5, I don't > see why iops and bytes couldn't be set at the same time. How did you manage > to set iops_sec_max to less than iops_sec (as seen in scenarios 4 and 5 as a > side effect)? as comment 3,nini has helped me explain it from the perspective of kvm
This bug was closed deferred as a result of bug triage. Please reopen if you disagree and provide justification why this bug should get enough priority. Most important would be information about impact on customer or layered product. Please indicate requested target release.