Could not reproduce this bug on the following components:
kernel-xen-2.6.18-238.el5
libvirt-0.8.2-15.el5
virt-manager-0.6.1-13.el5

Steps to Reproduce:
1.Define and start an isolated virtual network
# virsh net-list --all
Name                 State      Autostart
-----------------------------------------
br1                  active     yes        
default              active     yes       

# virsh net-dumpxml br1
<network>
  <name>br1</name>
  <uuid>b5c8a932-5d47-6760-b372-99e22a3a561a</uuid>
  <bridge name='virbr1' stp='on' delay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
    </dhcp>
  </ip>
</network>
2. Define and start a guest using the isolated virtual network
# virsh list
 Id Name                 State
----------------------------------
  0 Domain-0             running
  2 pv6.1                idle
# virsh dumpxml xenpv-rhel6u1-x86_64
.......
    <interface type='bridge'>
      <mac address='00:16:36:5a:6f:e2'/>
      <source bridge='virbr1'/>
      <script path='vif-bridge'/>
      <target dev='vif2.0'/>
    </interface>
......
3. Log in the guest and ping to google.com
4. # iptables -vnL FORWARD
  Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.100.0   0.0.0.0         255.255.255.0   U     1      0        0 eth0
0.0.0.0         192.168.100.1   0.0.0.0         UG    0      0        0 eth0

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

In my last comment, the result of step 3 is "could not ping to google.com".

In both test cases the configuration is not correct, and I believe this is leading to improper results.

The configuration in comment 1 is creating a libvirt virtual network named "br1" that creates a bridge device called "br1", then in the domain's interface XML is telling the guest to connect to a bridge device called *"virbr0"* - a completely unrelated device!

Beyond that, in both cases, rather than using the standard accepted method of connecting a guest's interface to a libvirt virtual network, eg:

   **CORRECT**
   <interface type='network'>
     <source network='br1'/>
     <mac address=='.....'/>
   </interface>
   **CORRECT**

(see http://wiki.libvirt.org/page/Networking) (and by the way, avoid using common names like "br1". Use something like "isolated" for the name of the network instead, to avoid confusion), you are connecting to the *bridge* that libvirt created for its virtual network as if it were a bridge created by the host's system config files:

   **WRONG**
   <interface type='bridge'>
     <source bridge='br1'/>
     ...
   **WRONG**

Finally, I'm not sure why you've included the

       <script path='vif-bridge'/>
       <target dev='vif32.0'/>

lines. These look like something that could be used to bypass libvirt's own virtual networks and connect to the network via an alternate method provided by Xen.

Because your test scenario seems to both incorrect and also not related to recommended/supported methods for using libvirt's virtual networks, I am closing this bug.

Please redo your testing in the following manner, and file a new bug (or re-open this bug if the results are the same) if you still experience a failure:


1) Create an isolated virtual network like this:

  <network>
    <name>isolated</name>
    <ip address='192.168.200.1'>
      <dhcp>
        <range start='192.168.200.2' end='192.168.200.254'/>
      </dhcp>
    </ip>
  </network>

(NB: libvirt will auto-generate a unique uuid and bridge device name)

2) configure your guest domain's interface XML like this (make sure there is only *1* <interface> element in the domain's XML!):

   <interface type='network'>
     <source network='isolated'/>
   </interface>

(NB: libvirt will auto-generate a unique mac address for the interface)

Now re-run the test.

According to comment 4 guide, I have re-tested this bug, the isolated virtual
network works well in xen guest. But a little information to update

After adding the following network interface xml into guest config xml
   <interface type='network'>
     <source network='isolated'/>
   </interface>
it is changed to bridge type automatically in guest config xml as below
    <interface type='bridge'>
      <mac address='00:16:3e:26:34:5c'/>
      <source bridge='virbr2'/>
      <script path='vif-bridge'/>
      <target dev='vif1.0'/>
    </interface>
I think it is correct, because bridge 'virbr2' is the same one with network
'isolated'
# virsh net-dumpxml isolated
<network>
  <name>isolated</name>
  <uuid>c3fdf1ce-8c39-1ba4-8c89-c65c3a3919dc</uuid>
  <bridge name='virbr2' stp='on' delay='0' />
  <ip address='10.0.0.1'>
  </ip>
</network>

The isolated virtual network works well means the guest A could ping to the host A but cannot ping to host B