[cinder] qos don t keep modifications
good evening, i was trying qos on cinder volumes, and it is working fine, BUT i found that if i modify the qos limits, or update or even remove them the actual vols that already have the previous iops limits do NOT thake new values...the newly created vols yes, the old ones not...is it a bug or is it normal?
here i create a 100 iops limit, set on volumes type, THEN modify it, even reboot istance, BUT old value persisist...
[image: image.png]
thank you.
On 29/01, garcetto wrote:
good evening, i was trying qos on cinder volumes, and it is working fine, BUT i found that if i modify the qos limits, or update or even remove them the actual vols that already have the previous iops limits do NOT thake new values...the newly created vols yes, the old ones not...is it a bug or is it normal?
here i create a 100 iops limit, set on volumes type, THEN modify it, even reboot istance, BUT old value persisist...
Hi,
I assume this is front-end QoS and not storage back-end QoS.
This is a known behavior, I think at some point there was a conversation about adding the feature you describe, which is updating front-end QoS for attached volumes, but afaik it was never implemented.
Maybe it will refresh the QoS values if you shelve the VM, wait for the shelve operation to complete and the instance to be completely shutoff before unshelve it, but I don't know.
Detaching and attaching the volume from the instance will refresh the QoS values for sure.
Cheers, Gorka.
[image: image.png]
thank you.
As of my understanding, the reason behind is that QOS are embeded in the instance xml.
On Tue, Jan 30, 2024, 14:48 Gorka Eguileor geguileo@redhat.com wrote:
On 29/01, garcetto wrote:
good evening, i was trying qos on cinder volumes, and it is working fine, BUT i found that if i modify the qos limits, or update or even remove them the actual vols that already have the previous iops limits do NOT thake new values...the newly created vols yes, the old ones not...is it a bug or is it normal?
here i create a 100 iops limit, set on volumes type, THEN modify it, even reboot istance, BUT old value persisist...
Hi,
I assume this is front-end QoS and not storage back-end QoS.
This is a known behavior, I think at some point there was a conversation about adding the feature you describe, which is updating front-end QoS for attached volumes, but afaik it was never implemented.
Maybe it will refresh the QoS values if you shelve the VM, wait for the shelve operation to complete and the instance to be completely shutoff before unshelve it, but I don't know.
Detaching and attaching the volume from the instance will refresh the QoS values for sure.
Cheers, Gorka.
[image: image.png]
thank you.
On 30/01, Cedric wrote:
As of my understanding, the reason behind is that QOS are embeded in the instance xml.
Hi,
Yes, but that's not all there is.
Cinder informs Nova of the QoS values of a volume in the connection information that is returned as part of the attach. Then Nova modifies the instance (XML).
When a user updates the QoS on Cinder that doesn't get propagated to nova, because there is no mechanism to do that, so Nova cannot update the QoS values of the instance.
Cheers, Gorka.
On Tue, Jan 30, 2024, 14:48 Gorka Eguileor geguileo@redhat.com wrote:
On 29/01, garcetto wrote:
good evening, i was trying qos on cinder volumes, and it is working fine, BUT i found that if i modify the qos limits, or update or even remove them the actual vols that already have the previous iops limits do NOT thake new values...the newly created vols yes, the old ones not...is it a bug or is it normal?
here i create a 100 iops limit, set on volumes type, THEN modify it, even reboot istance, BUT old value persisist...
Hi,
I assume this is front-end QoS and not storage back-end QoS.
This is a known behavior, I think at some point there was a conversation about adding the feature you describe, which is updating front-end QoS for attached volumes, but afaik it was never implemented.
Maybe it will refresh the QoS values if you shelve the VM, wait for the shelve operation to complete and the instance to be completely shutoff before unshelve it, but I don't know.
Detaching and attaching the volume from the instance will refresh the QoS values for sure.
Cheers, Gorka.
[image: image.png]
thank you.
participants (3)
-
Cedric
-
garcetto
-
Gorka Eguileor