Bug 1875805

Summary: Disk QoS not applied live (AttributeError: 'Drive' object has no attribute 'get')
Product: [oVirt] vdsm Reporter: Jean-Louis Dupond <jean-louis>
Component: CoreAssignee: Vojtech Juranek <vjuranek>
Status: CLOSED CURRENTRELEASE QA Contact: Ilan Zuckerman <izuckerm>
Severity: high Docs Contact:
Priority: high    
Version: 4.40.22CC: aefrat, aoconnor, bugs, michal.skrivanek, mzamazal, nsoffer, tnisan, vjuranek
Target Milestone: ovirt-4.4.2Keywords: Regression
Target Release: 4.40.26.2Flags: aoconnor: blocker+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: vdsm-4.40.26.2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-18 07:13:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jean-Louis Dupond 2020-09-04 12:30:05 UTC
Description of problem:
I noticed when I set a QoS on a disk, it was not applied directly.
After a reboot it worked fine.

Version-Release number of selected component (if applicable):
vdsm-4.40.22-1.el8
oVirt Node 4.4.1

How reproducible:
Set a QoS on a disk


Actual results:
QoS is only applied after a reboot.
VDSM log shows the following:
2020-09-04 14:03:20,664+0200 INFO  (jsonrpc/6) [api.virt] START setIoTune(tunables=[{'name': 'sdb', 'path': '/rhev/data-center/mnt/blockSD/bb9dfabe-588b-40d7-bb96-af7a03b396d5/images/1931de21-a0ce-4bd1-ace4-72e413c8cf10/6630cdb8-1f65-4996-b45a-c2ed160ae5f5', 'ioTune': {'total_bytes_sec': 0, 'read_bytes_sec': 0, 'write_bytes_sec': 0, 'total_iops_sec': 0, 'write_iops_sec': 0, 'read_iops_sec': 0}}]) from=::1,42440, vmId=6af39c68-75ed-4bb1-91fa-1abf7a02b072 (api:48)
2020-09-04 14:03:20,664+0200 ERROR (jsonrpc/6) [api] FINISH setIoTune error='Drive' object has no attribute 'get' (api:134)
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/vdsm/common/api.py", line 124, in method
    ret = func(*args, **kwargs)
  File "/usr/lib/python3.6/site-packages/vdsm/API.py", line 735, in setIoTune
    return self.vm.setIoTune(tunables)
  File "/usr/lib/python3.6/site-packages/vdsm/virt/vm.py", line 3369, in setIoTune
    device_name, device_path)
  File "/usr/lib/python3.6/site-packages/vdsm/virt/vm.py", line 3293, in find_device_by_name_or_path
    (device.get("path") == device_path)):
AttributeError: 'Drive' object has no attribute 'get'
2020-09-04 14:03:20,664+0200 INFO  (jsonrpc/6) [api.virt] FINISH setIoTune return={'status': {'code': 100, 'message': 'General Exception: ("\'Drive\' object has no attribute \'get\'",)'}} from=::1,42440, vmId=6af39c68-75ed-4bb1-91fa-1abf7a02b072 (api:54)
2020-09-04 14:03:20,665+0200 INFO  (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call VM.setIoTune failed (error 100) in 0.00 seconds (__init__:312)


Expected results:
QoS is live directly

Comment 1 Jean-Louis Dupond 2020-09-04 12:39:01 UTC
Error is here:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/virt/vm.py#L3304

(device.get("path") == device_path)):
-> changed it to
(device.path == device_path)):

Restarted vdsm, and it works!

Comment 2 Nir Soffer 2020-09-04 20:10:19 UTC
This is a regression in 4.4, caused by https://gerrit.ovirt.org/c/99313/.

The fix is trivial so we it can be delivered in 4.4.2.

Comment 8 Ilan Zuckerman 2020-09-16 04:59:24 UTC
Verified on rhv-4.4.2-8

1) Create in DC -> <DC name> -> QOS -> add a new storage profile (let it be 1MB total throughput) called "1MB"

2) Goto storage domains -> <SD name> -> disks profiles -> new -> add name and choose the QOS you created at step 1) "1MB"

3) Goto Disks -> create a NEW disk -> change the 'disk profile' to "1MB"

4) Attach the disk to a running VM and edit it

Expected: Editing the disk profile should succeed. No errors on VDSM log
Actual: As expected.

Comment 9 Sandro Bonazzola 2020-09-18 07:13:22 UTC
This bugzilla is included in oVirt 4.4.2 release, published on September 17th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.