[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Trouble with manual bridging on Xen3/CentOS 5
On 05/02/2011 01:33 PM, Teck Choon Giam wrote: > On Tue, May 3, 2011 at 12:10 AM, Digimer <linux@xxxxxxxxxxx> wrote: >> On 05/02/2011 12:04 PM, Teck Choon Giam wrote: >>> Ok, mind to show me your brctl show output? I am curious about what >>> is the vif?.? assignment to your xenbr2 especially. It is either >>> vif?.1 or vif?.2. Have you tried with vifname set in your domU >>> configs to see whether the same problem persist? >>> >>> Thanks. >> >> To get that info, I'd need to reconfigure a test cluster with the bugged >> patch. If it's curiosity only, I'd like to set it aside. If it could >> help with development though, let me know and I'll do so tonight. >> > > Curious only though but that might helps to determine one or more of > your patches issue. One of your patch at least is using vif?.N to get > its physical ethN if I am not mistaken: > > https://bugzilla.redhat.com/attachment.cgi?id=492964&action=diff That patch is now outdated, and was the one with the flaw. > pdev=`echo $dev | sed -e "s/^vif\(.*\)\.\(.*\)$/peth\2/"` > > So if $dev is vif?.N here, the pdev will be pethN right? However, > since you are using system network configuration to configure your > bridge, your physical ethN remain the same as it is and there isn't > any pethN here I believe. Correct me if I am wrong though :p peth=pethN, yes. At the time though, I was /not/ configuring the xenbrX devices in the system, I was letting Xen do it. When Xen does it, that is when the 'pethX' devices were created. Now that I am using system-built bridges, pethX devices no longer exist. > And your next line is: > > mtu=`cat /sys/class/net/$pdev/mtu` > > So if $pdev not set or empty or pethN not found, you will have issue here... > ... Exactly, however, $pdev was set to 'peth1' when the vif was about to be connected to xenbr2. The results were the same; The script failed, but the cause was different (the xenbr2 <-> peth1 mapping). > Now let said you are using xen provided to do the bridging instead of > using system network configuration... so pethN will be set by xen or > rename real ethN to pethN and setup bridge name as ethN if I remember > correctly... ... now if vif?.N where N is 1 for your xenbr2/peth2 you > will have issue as well :p Bingo. > You might want to try setting vifname for your testing domU config to > see whether does it resolve your issue? > > I haven't look closely for your other patches though and what I stated > above hopefully make sense :p > > Thanks. > > Kindest regards, > Giam Teck Choon I was able to make it work with a slight modification to a suggestion that Paolo gave me on IRC: https://bugzilla.redhat.com/attachment.cgi?id=496016&action=diff The change was that, at this point in the xen-network-common[-bonded].sh scripts, the 'vif' special file didn't exist, so I directly grabbed the MTU of the bridge instead. So far, this seems to be the winner. Testing will tell if there are new/remaining issues. -- Digimer E-Mail: digimer@xxxxxxxxxxx AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |