Question about the Qos support status for different type interfaces

Yalan Zhang yalzhang at redhat.com
Mon Mar 29 01:15:18 UTC 2021


Hi Michal,

Thank you for the clarification.


-------
Best Regards,
Yalan Zhang
IRC: yalzhang


On Fri, Mar 26, 2021 at 8:19 PM Michal Privoznik <mprivozn at redhat.com>
wrote:

> On 3/26/21 12:31 PM, Yalan Zhang wrote:
> > Hi there,
> >
> > I have a question about the Qos support status for different type
> > interfaces.
> > Some types of interface do not support Qos, such as hostdev, user type,
> > mcast type, but the behavior are different, for hostdev, the guest can
> > not start with a meaningful error message, but for other types, vm can
> > start successfully with a warning message in the libvirtd log. I
> > doubt that if it is necessary to keep the behavior consistent for these
> > different types?
> >
> > There are 2 history bugs for them, I should have thought further and
> > asked early when testing the bugs.
> > Bug 1319044 <https://bugzilla.redhat.com/show_bug.cgi?id=1319044>- log
> > error when <bandwidth> requested on a <interface type='hostdev'>
> > Bug 1524230 <https://bugzilla.redhat.com/show_bug.cgi?id=1524230>-
> > vhostuser type interface do not support bandwidth, but no warning message
> >
> > Thank you for looking into this and very appreciate your feedback!
> >
>
> The reason is historical baggage - as usual. When QoS was fist
> introduced it supported only a very few interface types. Soon we've
> learned that users put XML snippets in for other types too. Back then we
> had no validation callbacks => we could not reject such XMLs because we
> did not do it from the beginning. So there might be some domain XMLs
> still that contain QoS for unsupported type and those would be lost if
> libvirt started rejecting such XMLs.
>
> With validation callbacks things are a bit better - the domain would not
> be lost on libvirtd upgrade; though it would still be unable to start.
> I'm not sure that's much better.
>
> Hence, we're keeping status quo. I'm open for ideas though.
>
> Michal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20210329/7d3e6aa2/attachment.htm>


More information about the libvirt-users mailing list