Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1514963 - unable to start a network with bandwidth description for outbound QOS
Summary: unable to start a network with bandwidth description for outbound QOS
Alias: None
Product: Fedora
Classification: Fedora
Component: iproute
Version: 26
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Phil Sutter
QA Contact: Fedora Extras Quality Assurance
: 1514960 1514961 1514962 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-19 17:50 UTC by dravigon
Modified: 2018-02-26 11:02 UTC (History)
9 users (show)

Fixed In Version: iproute-4.14.1-4.fc26
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2018-02-26 11:02:55 UTC

Attachments (Terms of Use)
Libvirt client log (deleted)
2017-11-25 19:05 UTC, dravigon
no flags Details

Description dravigon 2017-11-19 17:50:26 UTC
Description of problem:
unable to start a network with bandwidth description for outbound QOS
my xml for network

  <forward dev='enp3s0' mode='nat'>
      <port start='1024' end='2048'/>
    <interface dev='enp3s0'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:90:cb:d0'/>
  <domain name='sda'/>
    <inbound average='50' peak='50' burst='50'/>
    <outbound average='50' peak='50' burst='50'/>
  <ip address='' netmask=''>

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

How reproducible:100%

Steps to Reproduce:
1.create a network with nat mode and with bandwith outbound rule in Qos
2.start the network

Actual results:
libvirt:  error : internal error: Child process (/usr/bin/tc filter add dev virbr0 parent ffff: protocol all u32 match u32 0 0 police rate 50kbps burst 50kb mtu 64kb drop flowid :1) unexpected exit status 1: What is ":1"?
Usage: ... u32 [ match SELECTOR ... ] [ link HTID ] [ classid CLASSID ]
               [ action ACTION_SPEC ] [ offset OFFSET_SPEC ]
               [ ht HTID ] [ hashkey HASHKEY_SPEC ]
               [ sample SAMPLE ] [skip_hw | skip_sw]
or         u32 divisor DIVISOR

       SAMPLE := { ip | ip6 | udp | tcp | icmp | u{32|16|8} | mark }
                 SAMPLE_ARGS [ divisor DIVISOR ]
       FILTERID := X:Y:Z

NOTE: CLASSID is parsed at hexadecimal input.
libvirt: Network Driver error : Network not found: no network with matching uuid 'a734e030-f800-4b72-a077-f360134bdc13' (sda)

Expected results:
Network must start automatically

Additional info:
qemu version :2.10.0
dnsmasq is installed

Comment 1 Cole Robinson 2017-11-19 23:26:30 UTC
*** Bug 1514960 has been marked as a duplicate of this bug. ***

Comment 2 Cole Robinson 2017-11-19 23:26:47 UTC
*** Bug 1514962 has been marked as a duplicate of this bug. ***

Comment 3 Cole Robinson 2017-11-19 23:27:12 UTC
*** Bug 1514961 has been marked as a duplicate of this bug. ***

Comment 4 Michal Privoznik 2017-11-24 21:31:02 UTC
Interesting. I'm unable to reproduce this bug. What's your kernel and iproute packages version? Can you please attach full debug logs?

Comment 5 dravigon 2017-11-25 19:05:39 UTC
Created attachment 1359023 [details]
Libvirt client log

This is the libvirt client log

Comment 6 dravigon 2017-11-25 19:36:17 UTC
This has my libvirt daemon log and I have attached my libvirt client log with this bug report

Comment 7 Michal Privoznik 2017-11-27 16:54:22 UTC
So I've managed to reproduce this issue. But only after I've upgraded tc to 4.13 or newer. I think the problem is the following tc's commit:

I'm investigating further.

Comment 8 Michal Privoznik 2017-11-27 18:17:31 UTC
So after some investigation I think I have fix:

Switching over to iproute & Fedora (e.g. F26 has 4.13 built which is affected).

Comment 9 Michal Privoznik 2017-12-08 10:22:06 UTC
After some discussion on the list, another approach was implemented:

Comment 10 Michal Privoznik 2017-12-28 10:06:31 UTC
The patch was merged upstream:

commit 3572e01a090a298e2f4c4f796bad6639b652e031
Author:     Michal Privoznik <>
AuthorDate: Fri Dec 8 11:18:07 2017 +0100
Commit:     Stephen Hemminger <>
CommitDate: Fri Dec 8 10:29:01 2017 -0800

    tc: util: Don't call NEXT_ARG_FWD() in __parse_action_control()
    Not all callers want parse_action_control*() to advance the
    arguments. For instance act_parse_police() does the argument
    advancing itself.
    Fixes: e67aba559581 ("tc: actions: add helpers to parse and print control actions")
    Signed-off-by: Michal Privoznik <>


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