[cinder]cinder qos question.
Hello guys. I am trying to use cinder qos. But i have question. - I added qos after a volume was create and I see that qos did not apply to this volume. - i create new volume with assosiate qos then it is ok but when i changed extra specs in qos, volume keep old specs. Is there any way to make qos apply with two above cases. Many thanks.
Hello guys, To apply qos on existing volumes or modify qos on volume type, I need live migrate instances. Is there any way to achieve this without my solution? Nguyen Huu Khoi On Tue, Jun 27, 2023 at 8:05 PM Nguyễn Hữu Khôi <nguyenhuukhoinw@gmail.com> wrote:
Hello guys. I am trying to use cinder qos. But i have question. - I added qos after a volume was create and I see that qos did not apply to this volume. - i create new volume with assosiate qos then it is ok but when i changed extra specs in qos, volume keep old specs. Is there any way to make qos apply with two above cases. Many thanks.
On 27/06, Nguyễn Hữu Khôi wrote:
Hello guys. I am trying to use cinder qos. But i have question. - I added qos after a volume was create and I see that qos did not apply to this volume. - i create new volume with assosiate qos then it is ok but when i changed extra specs in qos, volume keep old specs. Is there any way to make qos apply with two above cases. Many thanks.
Hi, I'm surprised you can even do it, I would expect this would be similar to changing a volume type when there's already a volume using it, which is not allowed. I assume you are using 'front-end' or 'both' QoS provider, because the situation is even worse for 'back-end' QoS providers. For front-end qos the values will NOT be updated in Nova until a new attachment is created, but it must be one that creates new connection information. Changing that would be a new feature requiring changes in Cinder and Nova, since Cinder would need to go through all the volumes that use volumes types associated with that QoS, check which ones are currently attached, update their connection_information in the cinder DB, and then report to Nova the new values (this API doesn't exist). For back-end QoS it would be driver dependent. I assume in most cases a retype would be necessary, but in some drivers they may be updating the QoS on the backed for all volumes once a new volume with that volume type or QoS is created. Cheers, Gorka.
hello. Thank you for your valuable information, I got this problem. Can you help me see how nova will be updated? I ask about something which I can touch or modify at nova manually, Nguyen Huu Khoi On Thu, Jul 13, 2023 at 5:10 PM Gorka Eguileor <geguileo@redhat.com> wrote:
On 27/06, Nguyễn Hữu Khôi wrote:
Hello guys. I am trying to use cinder qos. But i have question. - I added qos after a volume was create and I see that qos did not apply to this volume. - i create new volume with assosiate qos then it is ok but when i changed extra specs in qos, volume keep old specs. Is there any way to make qos apply with two above cases. Many thanks.
Hi,
I'm surprised you can even do it, I would expect this would be similar to changing a volume type when there's already a volume using it, which is not allowed.
I assume you are using 'front-end' or 'both' QoS provider, because the situation is even worse for 'back-end' QoS providers.
For front-end qos the values will NOT be updated in Nova until a new attachment is created, but it must be one that creates new connection information.
Changing that would be a new feature requiring changes in Cinder and Nova, since Cinder would need to go through all the volumes that use volumes types associated with that QoS, check which ones are currently attached, update their connection_information in the cinder DB, and then report to Nova the new values (this API doesn't exist).
For back-end QoS it would be driver dependent. I assume in most cases a retype would be necessary, but in some drivers they may be updating the QoS on the backed for all volumes once a new volume with that volume type or QoS is created.
Cheers, Gorka.
On 13/07, Nguyễn Hữu Khôi wrote:
hello. Thank you for your valuable information, I got this problem. Can you help me see how nova will be updated? I ask about something which I can touch or modify at nova manually,
Nguyen Huu Khoi
Hi, This is not something that can be easily fixed in the OpenStack code. There's always the manual hacking mechanism of changing things manually in libvirt using virsh without Nova knowing about it. I don't know the exact commands to run because I work on Cinder, but it's probably related to this old spec [1]. Making the code changes in OpenStack is non trivial, as it would require: - Add a new external event type to the Nova code to change the QoS for an instance. - Changing Cinder to do the following when QoS is updated: - Check volume types that use the updated QoS - Check volumes using those volume types - Check which volumes are connected to instances - For each of those volumes: - Update the connection information in the DB - Call Nova with the new external event type to update the instance. - If it's multi attached it may require making multiple calls for the same volume. Cheers, Gorka. [1]: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/enh...
On Thu, Jul 13, 2023 at 5:10 PM Gorka Eguileor <geguileo@redhat.com> wrote:
On 27/06, Nguyễn Hữu Khôi wrote:
Hello guys. I am trying to use cinder qos. But i have question. - I added qos after a volume was create and I see that qos did not apply to this volume. - i create new volume with assosiate qos then it is ok but when i changed extra specs in qos, volume keep old specs. Is there any way to make qos apply with two above cases. Many thanks.
Hi,
I'm surprised you can even do it, I would expect this would be similar to changing a volume type when there's already a volume using it, which is not allowed.
I assume you are using 'front-end' or 'both' QoS provider, because the situation is even worse for 'back-end' QoS providers.
For front-end qos the values will NOT be updated in Nova until a new attachment is created, but it must be one that creates new connection information.
Changing that would be a new feature requiring changes in Cinder and Nova, since Cinder would need to go through all the volumes that use volumes types associated with that QoS, check which ones are currently attached, update their connection_information in the cinder DB, and then report to Nova the new values (this API doesn't exist).
For back-end QoS it would be driver dependent. I assume in most cases a retype would be necessary, but in some drivers they may be updating the QoS on the backed for all volumes once a new volume with that volume type or QoS is created.
Cheers, Gorka.
Thank you much. I try to understand it. I will feedback if I can do something, Nguyen Huu Khoi On Thu, Jul 13, 2023 at 6:45 PM Gorka Eguileor <geguileo@redhat.com> wrote:
On 13/07, Nguyễn Hữu Khôi wrote:
hello. Thank you for your valuable information, I got this problem. Can you help me see how nova will be updated? I ask about something which I can touch or modify at nova manually,
Nguyen Huu Khoi
Hi,
This is not something that can be easily fixed in the OpenStack code.
There's always the manual hacking mechanism of changing things manually in libvirt using virsh without Nova knowing about it. I don't know the exact commands to run because I work on Cinder, but it's probably related to this old spec [1].
Making the code changes in OpenStack is non trivial, as it would require:
- Add a new external event type to the Nova code to change the QoS for an instance.
- Changing Cinder to do the following when QoS is updated:
- Check volume types that use the updated QoS - Check volumes using those volume types - Check which volumes are connected to instances - For each of those volumes: - Update the connection information in the DB - Call Nova with the new external event type to update the instance. - If it's multi attached it may require making multiple calls for the same volume.
Cheers, Gorka.
[1]: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/enh...
On Thu, Jul 13, 2023 at 5:10 PM Gorka Eguileor <geguileo@redhat.com>
wrote:
On 27/06, Nguyễn Hữu Khôi wrote:
Hello guys. I am trying to use cinder qos. But i have question. - I added qos after a volume was create and I see that qos did not
to
this volume. - i create new volume with assosiate qos then it is ok but when i changed extra specs in qos, volume keep old specs. Is there any way to make qos apply with two above cases. Many thanks.
Hi,
I'm surprised you can even do it, I would expect this would be similar to changing a volume type when there's already a volume using it, which is not allowed.
I assume you are using 'front-end' or 'both' QoS provider, because the situation is even worse for 'back-end' QoS providers.
For front-end qos the values will NOT be updated in Nova until a new attachment is created, but it must be one that creates new connection information.
Changing that would be a new feature requiring changes in Cinder and Nova, since Cinder would need to go through all the volumes that use volumes types associated with that QoS, check which ones are currently attached, update their connection_information in the cinder DB, and
apply then
report to Nova the new values (this API doesn't exist).
For back-end QoS it would be driver dependent. I assume in most cases a retype would be necessary, but in some drivers they may be updating the QoS on the backed for all volumes once a new volume with that volume type or QoS is created.
Cheers, Gorka.
participants (2)
-
Gorka Eguileor
-
Nguyễn Hữu Khôi