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