libvirt users - Mar 2021 - Question about the Qos support status for different type interfaces

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!

1. start vm with user type interface set with Qos:
 <interface type='user'>
      <mac address='52:54:00:3e:ec:14'/>
      <bandwidth>
        <inbound average='1000' peak='5000'
burst='5120'/>
        <outbound average='128' peak='256'
burst='256'/>
      </bandwidth>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x07'
slot='0x01'
function='0x0'/>
    </interface>

# cat /var/log/libvirt/libvirtd.log | grep bandwidth
2021-03-26 10:47:11.452+0000: 20185: warning :
qemuBuildInterfaceCommandLine:8223 : setting bandwidth on interfaces of
type 'user' is not implemented yet

2. start with hostdev type interface with Qos setting:
<interface type='hostdev' managed='yes'>
      <mac address='52:54:00:07:27:b0'/>
      <source>
        <address type='pci' domain='0x0000'
bus='0x82' slot='0x10'
function='0x6'/>
      </source>
      <bandwidth>
        <inbound average='1000' peak='5000'
burst='5120'/>
        <outbound average='128' peak='256'
burst='256'/>
      </bandwidth>
      <address type='pci' domain='0x0000' bus='0x01'
slot='0x00'
function='0x0'/>
    </interface>

# virsh start rh
error: Failed to start domain 'rh'
error: unsupported configuration: interface 52:54:00:07:27:b0 - bandwidth
settings are not supported for hostdev interfaces


-------
Best Regards,
Yalan Zhang
IRC: yalzhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20210326/9204f751/attachment.htm>

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