Bug 835055

Summary: VM fails to start if any NIC device bandwidth limits are set
Product: [Fedora] Fedora Reporter: Daniel Berrange <berrange>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 17CC: berrange, clalancette, crobinso, dallan, dougsland, eblake, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-20 19:35:58 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 836185    
Bug Blocks:    

Description Daniel Berrange 2012-06-25 07:20:10 EDT
Description of problem:
Create a guest with NIC device bandwidth limits set eg

    <interface type='bridge'>
      <mac address='52:54:00:66:a5:e4'/>
      <source bridge='br0'/>
      <model type='virtio'/>
        <inbound average='1000' peak='5000' burst='1024'/>
        <outbound average='128' peak='256' burst='256'/>

any attempt to start the guest will fail.

This appears to be a regression from Fedora 16. I'm not clear if there was a kernel change which causes this, or a libvirt change.

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

How reproducible:

Steps to Reproduce:
1. virsh edit $GUESTNAME
2. Add to a <interface>:
        <inbound average='1000' peak='5000' burst='1024'/>
        <outbound average='128' peak='256' burst='256'/>
3. virsh start $GUESTNAME
Actual results:
error: internal error cannot set bandwidth limits on vnet0

Expected results:
VM starts

Additional info:
Comment 1 Michal Privoznik 2012-06-27 13:16:28 EDT
This is caused by F17 kernel not having the QoS anymore:

2012-06-27 17:05:59.857+0000: 12566: debug : virCommandRunAsync:2174 : About to run /sbin/tc qdisc add dev vnet0 root handle 1: htb default 1
2012-06-27 17:05:59.857+0000: 12566: debug : virCommandRunAsync:2192 : Command result 0, with PID 12672
2012-06-27 17:05:59.861+0000: 12566: error : virCommandWait:2306 : internal error Child process (/sbin/tc qdisc add dev vnet0 root handle 1: htb default 1) status unexpected: exit status 2
2012-06-27 17:05:59.861+0000: 12566: debug : virCommandRun:1994 : Result status 0, stdout: '' stderr: '2012-06-27 17:05:59.858+0000: 12672: info : libvirt version:, package: 1.fc17 (Fedora Project, 2012-04-27-21:26:56, x86-06.phx2.fedoraproject.org)
2012-06-27 17:05:59.858+0000: 12672: debug : virCommandHook:2093 : Hook is done 0
RTNETLINK answers: No such file or directory

the HTB packet scheduling algorithm should be provided by sch_htb module. However, there is no such module:

# find /lib/modules/ -iname "*htb*" | wc -l
Comment 2 Dave Allan 2012-06-27 13:51:33 EDT
Is that deliberate?
Comment 3 Michal Privoznik 2012-06-28 05:58:35 EDT
Yeah it seems like that. They have decided to move kernel modules providing QoS into a separate package called kernel-modules-extra in F17. In previous releases those modules were part of main kernel. I've filled a bug against F17 - bug 836185. I am adding it as dependency of this bug as well.
Comment 4 Dave Allan 2012-06-28 09:06:22 EDT
Ok, that may be, but in the meantime we have what is IMO a fairly nasty regression, so let's not stand too much on architectural beauty if it will prevent a quick resolution.
Comment 5 Daniel Berrange 2012-06-28 09:18:19 EDT
There's nothing we can or should do about this in libvirt. Given the kernel developers decision to move the module, the system is working as they intended. Obviously the kernel packaging decision was wrong, since it inconveniences libvirt users, and the module should be moved in the main kernel RPM.
Comment 6 Eric Blake 2012-06-28 09:25:55 EDT
Should libvirt change its spec file to add a Requires: kernel-modules-extra to work around the kernel packaging decision?
Comment 7 Daniel Berrange 2012-06-28 09:48:06 EDT
No I don't think it should do that. The intent the kernel developers is that the 'extras' package never needs to be installed on Fedora for any normal usage requirements. Virtualization fits that, and thus I don't think we should be forcing its install.
Comment 8 Cole Robinson 2012-10-20 19:35:58 EDT
The kernel bug was closed, so this is fixed now.