Red Hat Bugzilla – Full Text Bug Listing
|Summary:||VM fails to start if any NIC device bandwidth limits are set|
|Product:||[Fedora] Fedora||Reporter:||Daniel Berrange <berrange>|
|Component:||libvirt||Assignee:||Michal Privoznik <mprivozn>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||17||CC:||berrange, clalancette, crobinso, dallan, dougsland, eblake, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-10-20 19:35:58 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||836185|
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'/> <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> </interface> 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): libvirt-0.9.11.3-1.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. virsh edit $GUESTNAME 2. Add to a <interface>: <bandwidth> <inbound average='1000' peak='5000' burst='1024'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> 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: 0.9.11.3, 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 0
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.