Hi Michal, Thank you for the clarification.
------- Best Regards, Yalan Zhang IRC: yalzhang On Fri, Mar 26, 2021 at 8:19 PM Michal Privoznik <mpriv...@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 > >