Bug 1377648
Summary: | some logic issues for blkdeviotune | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | lijuan men <lmen> |
Component: | libvirt | Assignee: | Virtualization Maintenance <virt-maint> |
Status: | CLOSED DEFERRED | QA Contact: | yisun |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.0 | CC: | dyuan, lmen, ngu, rbalakri, stefanha, xuzhang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-02-11 13:24:31 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
lijuan men
2016-09-20 09:36:08 UTC
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. |