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.