Red Hat Bugzilla – Bug 1346754
[z-stream clone - 3.6.8] Storage QoS is not applying on a Live VM/disk
Last modified: 2016-09-21 14:04:07 EDT
Tested with the following code: ------------------------------------- rhevm-3.6.9-0.1.el6.noarch vdsm-4.17.34-1.el7ev.noarch Verified with the following scenario: ------------------------------------- Steps to reproduce: Tested with the following scenario: 1. Created a VM with disks, started the VM and wrote to the disk with 'dd' as described in the description dd bs=1M count=100 if=/dev/zero of=/mnt/1/aaa conv=fdatasync 105mb written in 90mb/s 2. Added a new profile via the Data Centre tab 3. Added this profile to the Domain Controller via the Storage tab 4. Via the VM tab select a disk from the disk tab in the VM and pressed edit and changed the profile to the newly created profile of 10MB write limit 5. Wrote to the disk again but the limit is NOT APPLIED! dd bs=1M count=100 if=/dev/zero of=/100Mb conv=fdatasync 10bmb written in 86 MB/s 6. After Shutting down the VM and Starting it again run the write operation again. Now it works fine. dd bs=1M count=100 if=/dev/zero of=/100Mf conv=fdatasync 10bmb written in 10.5 MB/s MOVING TO ASSIGNED!
Created attachment 1195437 [details] vdsm, mom, server and engine logs Adding logs
What is the mom version you used?
(In reply to Doron Fediuck from comment #5) > What is the mom version you used? mom-0.5.5-1.el7ev.noarch
(In reply to Kevin Alon Goldblatt from comment #6) > (In reply to Doron Fediuck from comment #5) > > What is the mom version you used? > > mom-0.5.5-1.el7ev.noarch mom 0.5.5 does not contain patch [1] which is the last of the patch series from Bug 1201482. The issue here is that when you start the VM without or the unlimited default disk profile, mom will not pick up the live changes from libvirt/vdsm. To see if this is the issue, assign a disk profile which is not completely unlimited to a VM while it is down. After the VM is running, verify that it works. Then switch the profile and do verify with dd if the new values are taken. If this scenario works, then the only thing missing is a new mom release. [1] https://gerrit.ovirt.org/#/c/61947/
(In reply to Roman Mohr from comment #7) > (In reply to Kevin Alon Goldblatt from comment #6) > > (In reply to Doron Fediuck from comment #5) > > > What is the mom version you used? > > > > mom-0.5.5-1.el7ev.noarch > > mom 0.5.5 does not contain patch [1] which is the last of the patch series > from Bug 1201482. But this is the last mom that was published to QE. Please See: http://bob.eng.lab.tlv.redhat.com/builds/3.6/3.6.9-1/el7/3.6.9-1_version_info.html It clearly shows: 0.5.5-1.el7ev.noarch I also can not find a new mom erratum in the 3.6.9 errata batch: https://errata.devel.redhat.com/batches/60 Can you please check why was it missed? > > The issue here is that when you start the VM without or the unlimited > default disk profile, mom will not pick up the live changes from > libvirt/vdsm. > > To see if this is the issue, assign a disk profile which is not completely > unlimited to a VM while it is down. After the VM is running, verify that it > works. Then switch the profile and do verify with dd if the new values are > taken. If this scenario works, then the only thing missing is a new mom > release. > > [1] https://gerrit.ovirt.org/#/c/61947/
The remaining issue with hoplug not working when no QoS was defined during VM start will disappear when mom-0.5.6 is released.
(In reply to Martin Sivák from comment #9) > The remaining issue with hoplug not working when no QoS was defined during > VM start will disappear when mom-0.5.6 is released. What's the ETA for mom-0.5.6 to be released? Would it make it to 3.6.9 or should we retarget this verification to 3.6.10 ?
Moving back to MODIFIED till we get a mom-0.5.6 erratum + d/s build for QE to consume
Gil, mom-0.5.6 was released as part of yesterday's builds (both 3.6.9 and 4.0.4) so you should be fine.
Tested with the following code: ---------------------------------------- rhevm-3.6.9.1-0.1.1.el6.noarch vdsm-4.17.35-1.el7ev.noarch Tested with the following scenario: Steps to Reproduce: Steps to reproduce: Tested with the following scenario: 1. Created a VM with disks, started the VM and wrote to the disk with 'dd' as described in the description dd bs=1M count=100 if=/dev/zero of=/mnt/1/aaa conv=fdatasync 105mb written in 96mb/s 2. Added a new profile via the Data Centre tab 3. Added this profile to the Domain Controller via the Storage tab 4. Via the VM tab select a disk from the disk tab in the VM and pressed edit and changed the profile to the newly created profile of 10MB write limit 5. Wrote to the disk again and the limit is NOW APPLIED! dd bs=1M count=100 if=/dev/zero of=/100Mb conv=fdatasync 10bmb written in 10 MB/s Actual results: QoS limit is NOW APPLIED! Expected results:ap Moving to VERIFIED!
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://rhn.redhat.com/errata/RHSA-2016-1929.html