Bug 743176
Summary: | bandwidth info in <portgroup> isn't used if forward mode='nat|route|bridge|none' | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Laine Stump <laine> |
Component: | libvirt | Assignee: | Laine Stump <laine> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.1 | CC: | acathrow, ajia, dallan, mjenner, mzhan, rwu, xhu |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-0.9.4-15.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-12-06 11:35:00 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 747120 |
Description
Laine Stump
2011-10-04 04:13:58 UTC
I've posted a patch for this bug to the upstream libvirt list: https://www.redhat.com/archives/libvir-list/2011-October/msg00059.html Once it's ACKed and pushed, I will post a rebase for RHEL. The patch has been pushed upstream, and a rebased version posted to rhvirt patches for inclusion in the next RHEL build: http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-October/msg00136.html commit 6c9e2eb23bd11279adcf49fec304602efeaeff8d Author: Laine Stump <laine> Date: Mon Oct 3 23:53:36 2011 -0400 network: fill in bandwidth from portgroup for all forward modes Background: Although virtportprofile data from a network portgroup is only applicable for direct mode interfaces, the code that copies bandwidth data from the portgroup was also only being executed in the case of direct mode interfaces. The result was that interfaces using traditional virtual networks (forward mode='nat|route|none'), and those using a host bridge for forwarding, would not pick up bandwidth data from a portgroup defined in the network. This patch moves that code outside the conditional, so that bandwidth information is *alway* copied from the appropriate portgroup (unless the <interface> definition itself already has bandwidth information, which would take precedence over what's in the portgroup anyway). Hi Laine, The following are my test steps with libvirt-0.9.4-16.el6.x86_64, I'm not sure whether these are enough for you, please correct me if not, thanks. # virsh net-list Name State Autostart ----------------------------------------- default active yes net-portgroup active no # virsh net-dumpxml net-portgroup <network> <name>net-portgroup</name> <uuid>5bb42a33-f3b1-03b6-8202-bb8d5d63f199</uuid> <forward mode='nat'/> <bridge name='virbr2' stp='on' delay='0' /> <mac address='52:54:00:A5:69:F9'/> <ip address='192.168.120.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.120.2' end='192.168.120.254' /> </dhcp> </ip> <portgroup name='engineering' default='yes'> <virtualport type='802.1Qbh'> <parameters profileid='test'/> </virtualport> <bandwidth> <inbound average='1000' peak='5000' burst='5120'/> <outbound average='1000' peak='5000' burst='5120'/> </bandwidth> </portgroup> <portgroup name='sales'> <virtualport type='802.1Qbh'> <parameters profileid='salestest'/> </virtualport> <bandwidth> <inbound average='500' peak='2000' burst='2560'/> <outbound average='128' peak='256' burst='256'/> </bandwidth> </portgroup> </network> # virsh edit vr-rhel5u4-x86_64-kvm Domain vr-rhel5u4-x86_64-kvm XML configuration edited. Notes, to replace 'default' with 'net-portgroup' in interface element of guest xml, it looks like this: <source network='net-portgroup'/> # virsh start vr-rhel5u4-x86_64-kvm Domain vr-rhel5u4-x86_64-kvm started # tc class show dev vnet0 class htb 1:1 root prio 0 rate 8000Kbit ceil 40000Kbit burst 5Mb cburst 1600b Notes: 'engineering' is a default portgroup, and it works well. (In reply to comment #5) > The following are my test steps with libvirt-0.9.4-16.el6.x86_64, I'm not sure > whether these are enough for you, please correct me if not, thanks. Yes, assuming that explicitly specifying the portgroup name in the <interface> definition is tested elsewhere (eg with type='bridge' interfaces), the test you outline above is enough to verify that portgroup has been properly plugged into nat|routed networks. So you can safely move this bug to verified if that test passes. (In reply to comment #6) > Yes, assuming that explicitly specifying the portgroup name in the <interface> > definition is tested elsewhere (eg with type='bridge' interfaces), the test you Hi Laine, If I specify portgroup name in the <interface> definition and let interface type='bridge' in guest XML, 'portgroup' property will be gone when save & quit 'virsh edit', please correct me if I'm making a mistake , the following is a slice of interface (I have a virbr1 bridge): <slice> <interface type='bridge'> <mac address='52:54:00:80:4d:ac'/> <source bridge='virbr1' portgroup='alice'/> <model type='rtl8139'/> </interface> </slice> However, it's okay for type='network' in <interface> definition: # virsh dumpxml vr-rhel6u2-x86_64-kvm <interface type='network'> <mac address='52:54:00:80:4d:ac'/> <source network='portgroup-net' portgroup='alice'/> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> # virsh net-list Name State Autostart ----------------------------------------- default active yes portgroup-net active no # virsh net-dumpxml portgroup-net <network> <name>portgroup-net</name> <uuid>b93605a9-3cb8-43cd-971e-a480ad718052</uuid> <forward mode='nat'/> <bridge name='virbr1' stp='on' delay='0' /> <mac address='52:54:00:75:27:EE'/> <ip address='192.168.120.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.120.2' end='192.168.120.254' /> </dhcp> </ip> <portgroup name='bob' default='yes'> <bandwidth> <inbound average='1000' peak='5000' burst='5120'/> <outbound average='1000' peak='5000' burst='5120'/> </bandwidth> </portgroup> <portgroup name='alice'> <bandwidth> <inbound average='1500' peak='2000' burst='2560'/> <outbound average='1500' peak='2000' burst='2560'/> </bandwidth> </portgroup> </network> # tc class show dev vnet0 class htb 1:1 root prio 0 rate 12000Kbit ceil 16000Kbit burst 2560Kb cburst 1600b Thanks, Alex Shoot! You're right. Although the backend of the code for bridge and direct type interfaces now uses portgroup, the parser for interface still doesn't recognize/save it unless the interface type='network'. I'm making a patch to fix that now. Sigh. I don't know what I was thinking about in Comment 8. I must not have had enough sleep. portgroup *shouldn't* work when the interface type specified in the domain's <interface> is something other than "network". As a matter of fact it *can't*, since the portgroup name is used to look up a portgroup in a <network> definition, and there is no network definition to look it up in unless type="network". So, the test in Comment 7 is incorrect (probably due to my poorly worded Comment 6, where I see it can be understood I'm talking about the <interface> definition itself being of type=bridge); sorry I didn't catch that and point it out before. The "other testing" that I meant to be talking about was the case where you have an interface definition of type='network' that points to a <network> definition with <forward mode="bridge|private|passthrough" ... /> For example: <interface type='network'/> <source network='host-bridge' portgroup='bob'/> </interface> And separately in the network definitions: <network> <name>host-bridge</name> <forward mode="bridge"/> <bridge name="br0"/> <portgroup name='bob'> <bandwidth> <inbound average='1000' peak='5000' burst='5120'/> <outbound average='1000' peak='5000' burst='5120'/> </bandwidth> </portgroup> </network> Of course, that was presumably tested as a part of the basic functionality outlined in Bug 643947; I was just saying that testing with a default portgroup was adequate for the purposes of the current bug, as long as the testing above had been done for Bug 643947. If you want to be sure, you can perform the same test you did in Comment 5, just replacing "<source network='net-portgroup'/>" in the <interface> definition with "<source network='net-portgroup' portgroup='sales'/>. Now that I've realized my mistake, and (hopefully) cleared up the misunderstanding, I'm moving this back to ON_QA. If you like, you can redo the test in Comment 5 changed as I outline in the previous paragraph, and that will be adequate to verify that it's fixed. (In reply to comment #9) > portgroup *shouldn't* work when the interface type specified in the domain's > <interface> is something other than "network". As a matter of fact it *can't*, > since the portgroup name is used to look up a portgroup in a <network> > definition, and there is no network definition to look it up in unless > type="network". If so, whether we need to document these stuff in virsh man page or libvirt.org. > > So, the test in Comment 7 is incorrect (probably due to my poorly worded > Comment 6, where I see it can be understood I'm talking about the <interface> > definition itself being of type=bridge); sorry I didn't catch that and point it > out before. It doesn't matter. > > The "other testing" that I meant to be talking about was the case where you > have an interface definition of type='network' that points to a <network> > definition with <forward mode="bridge|private|passthrough" ... /> Now I know you mean. > > Of course, that was presumably tested as a part of the basic functionality > outlined in Bug 643947; I was just saying that testing with a default portgroup > was adequate for the purposes of the current bug, as long as the testing above > had been done for Bug 643947. Yeah, I use default portgroup in <network> definition from Comment 5, so I haven't specified portgroup name in <interface> definition of guest XML again. > Laine, thanks for your nice comment. 1. The comment 5 has tested default portgroup scenario in <interface> definition of guest XML: <source network='net-portgroup'/> in <network> definition: <portgroup name='engineering' default='yes'> <virtualport type='802.1Qbh'> <parameters profileid='test'/> </virtualport> <bandwidth> <inbound average='1000' peak='5000' burst='5120'/> <outbound average='1000' peak='5000' burst='5120'/> </bandwidth> </portgroup> Actual result: # tc class show dev vnet0 class htb 1:1 root prio 0 rate 8000Kbit ceil 40000Kbit burst 5Mb cburst 1600b 2. And the comment 7 has also tested a specified portgroup scenario: in <interface> definition of guest XML: <source network='portgroup-net' portgroup='alice'/> in <network> definition: <portgroup name='alice'> <bandwidth> <inbound average='1500' peak='2000' burst='2560'/> <outbound average='1500' peak='2000' burst='2560'/> </bandwidth> </portgroup> Actual result: # tc class show dev vnet0 class htb 1:1 root prio 0 rate 12000Kbit ceil 16000Kbit burst 2560Kb cburst 1600b In addition, for other mode in <network> such as <forward mode="bridge|private|passthrough" ... />, the previous Bug 643947 had done it, so move the bug to VERIFIED status. 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. http://rhn.redhat.com/errata/RHBA-2011-1513.html |