Bug 503986 - Virtualization bridge numbers appear to increment upon each new installation of the rhn-virtualization packages
Summary: Virtualization bridge numbers appear to increment upon each new installation ...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Virtualization
Version: 530
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: 462714
TreeView+ depends on / blocked
 
Reported: 2009-06-03 17:08 UTC by Steve Salevan
Modified: 2014-07-04 13:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-04 13:29:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Steve Salevan 2009-06-03 17:08:31 UTC
Description of problem:
For some reason that Wes and I haven't quite been able to divine, the xenbr<x> bridge numbers seem to increment upon systems serving as RHN Virtualization Hosts.  Our best guess as to why this is happening involves the reinstallation of the rhn-virtualization packages that occurs when a machine is re-entitled as a virtualization host on a Satellite.

Version-Release number of selected component (if applicable):
530, 5/29 build

How reproducible:
Deterministic

Steps to Reproduce:
1. Register and entitle a virtualization-capable machine to a Satellite, then run rhn_check
2. Follow Steely Dan's advice and do it again
3. Run ifconfig
  
Actual results:
xenbr<x> number incremented

Expected results:
xenbr<x> number not incremented

Additional info:

Comment 1 Devan Goodwin 2009-06-10 13:45:48 UTC
I cannot seem to reproduce this.

Could you clarify what you meant for step 2 by do it again? Was that just re-run rhn_check? Or remove virt entitlement, re-add it, then run run_check? Or re-register the machine entirely and start all over?

I've tried all three to be honest and can't get this to happen so any additional information you could provide would be useful.

Thanks!

Comment 2 Devan Goodwin 2009-06-10 14:26:51 UTC
It looks like xenbr0 tends to be created by /etc/xen/scripts/network-bridge, which can be called with arguments to create specific interfaces but I doubt that's what's going on here and I can find no places where we call this in our code.

In normal execution it's called from /etc/xen/xend-config.sxp with:

(network-script network-bridge)

The script looks like it uses this to define the interface number:

vifnum=${vifnum:-$(ip route list | awk '/^default / { print $NF }' | sed 's/^[^0-9]*//')}
vifnum=${vifnum:-0}
bridge=${bridge:-xenbr${vifnum}}

Any chance there were networking/routing changes being made on this system between steps here?

Comment 3 Devan Goodwin 2009-06-10 14:27:54 UTC
Near as I can tell the script above is grabbing the 0 from eth0 on my system in the results of ip route list:

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.20 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
169.254.0.0/16 dev eth0  scope link 
default via 192.168.1.1 dev eth0 

Could I get a list of network interfaces available on the system this appeared on?


Note You need to log in before you can comment on or make changes to this bug.