Bug 1319044 - log error when <bandwidth> requested on a <interface type='hostdev'>
Summary: log error when <bandwidth> requested on a <interface type='hostdev'>
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2016-03-18 14:17 UTC by yalzhang@redhat.com
Modified: 2016-11-03 18:40 UTC (History)
4 users (show)

Fixed In Version: libvirt-1.3.5-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-11-03 18:40:02 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2577 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Description yalzhang@redhat.com 2016-03-18 14:17:36 UTC
Description of problem:
Interface of hostdev type support bandwidth setting while it is not effective.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
# virsh attach-interface rhel7.2 hostdev 0000:03:10:5 --inbound 1000,2000,1024 --outbound 1000,2000,1024 --persistent --managed --mac aa:bb:cc:dd:aa:11
Interface attached successfully

# virsh dumpxml rhel7.2 | grep /interface -B12
   <interface type='hostdev' managed='yes'>
      <mac address='aa:bb:cc:dd:aa:11'/>
      <driver name='vfio'/>
        <address type='pci' domain='0x0000' bus='0x03' slot='0x10' function='0x5'/>
        <inbound average='1000' peak='2000' burst='1024'/>
        <outbound average='1000' peak='2000' burst='1024'/>
      <alias name='hostdev1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>

# virt-xml-validate rhel7.2.xml
rhel7.2.xml validates

#scp V.qcow2
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is b1:69:87:18:a0:4d:9c:cc:54:86:87:5f:e7:a3:6e:41.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
root@'s password:
V.qcow2                                                                                    100% 1906MB  47.7MB/s   00:40    

Actual results:
To define bandwidth in interface of hostdev type will succeed.And the bandwidth setting can be stored and validate.

Expected results:
For type of hostdev, should not support bandwidth definition.

Addtional info:
The <bandwidth> element allows setting quality of service for a particular network (since 0.9.4). Setting bandwidth for a network is supported ** only for networks with a <forward> mode of route, nat, or no mode at all (i.e. an "isolated" network).** Setting bandwidth is not supported for forward modes of bridge, passthrough, private, or hostdev. Attempts to do this will lead to a failure to define the network or to create a transient network. -----from libvirt.org

I have tried to define bandwidth on different interface type, Qos control is ** supported** by type of macvtap(bridge, private, vepa, passthrough), hostdev, bridge mode.
Only for hostdev type it is not functional, the other type of interfaces will comply with the Qos restriction. That is, If I copy a file, the rate will be fast at the beginning then gradually fall to a stable rate as I specified in the bandwidth element "average".

Comment 2 Laine Stump 2016-04-10 02:39:19 UTC
There are some SRIOV network cards that support simple QoS settings for VFs (I can't remember which card I saw it on, but it was one that I don't have).

So in general this just needs to be added to validation of the config - if it's a hostdev interface and there is a bandwidth setting, then we should flag it as an error. One problem with this is that there may be existing setups in the wild that are putting a <bandwidth> element into every interface, and upgrading libvirt then cause a previously working configuration to fail.

Comment 3 Laine Stump 2016-05-13 14:06:26 UTC
Patch pushed upstream to log error when <bandwidth> element is encountered in a hostdev interface definition:

commit 9575cb855403f6aa20ffb0ae8c12179115c4aced
Author: Laine Stump <laine@laine.org>
Date:   Wed Apr 27 12:57:08 2016 -0400

    network: log error when <bandwidth> is requested for hostdev interfaces

Comment 5 yalzhang@redhat.com 2016-06-08 09:51:14 UTC
verified on libvirt-1.3.5-1.el7.x86_64, the result is as expected.

1. hotplug an interface
# virsh attach-interface R7.2 hostdev 0000:03:10:5 --inbound 1000,2000,1024  --managed
error: Failed to attach interface
error: unsupported configuration: bandwidth settings are not supported for hostdev interfaces

2. plug an interface when the guest is offline
# virsh attach-interface R7.2 hostdev 0000:03:10:5 --inbound 1000,2000,1024  --managed --persistent
Interface attached successfully

# virsh start R7.2
error: Failed to start domain R7.2
error: unsupported configuration: bandwidth settings are not supported for hostdev interfaces

3. start or create a guest with bandwidth defined in hostdev interface 
# virsh define R7.2.xml
Domain R7.2 defined from R7.2.xml
# virsh start R7.2
error: Failed to start domain R7.2
error: unsupported configuration: bandwidth settings are not supported for hostdev interfaces

# virsh create R7.2.xml
error: Failed to create domain from R7.2.xml
error: unsupported configuration: bandwidth settings are not supported for hostdev interfaces

4.For a libvirt update, when a guest with hostdev interface is running on the old libvirt, and there is bandwidth defined in the interface, after update the libvirt to 1.3.5, the network still works fine in the guest. But after destroy, the guest can not start again with the same error message in step2.

move the bug to verified.

Comment 7 errata-xmlrpc 2016-11-03 18:40:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.