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