Rob, Thanks for the confirmation. I've issued the pull request (#1180) just now (I hope...).
KRT On Tue, Apr 30, 2013 at 3:11 AM, Rob Hoes <[email protected]> wrote: > Hi Kevin,**** > > ** ** > > Thanks for the report. Your analysis of the problem sounds correct. I did > not realise that this was not working on VLANs.**** > > ** ** > > If you could create a pull request to the xen-api repo on github that > would be great. Feel free to send questions to the list if you need help > with this.**** > > ** ** > > Cheers,**** > > Rob**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Kevin Tower > *Sent:* 30 April 2013 5:51 AM > *To:* [email protected] > *Subject:* [Xen-API] Bug (and fix?) for scripts/setup-vif-rules**** > > ** ** > > Hello,**** > > ** ** > > My name is Kevin Tower and I am a systems engineer and self-proclaimed > virtualization evangelist at the University of Washington. We make use of > the downstream fork of XCP -- XenSever, but I use XCP in some of my > personal dev environments. We have been attempting to make use of the > "port locking" functionality that was added in 6.1 / 1.6, but I believe it > to be broken. Details of the issue follow, as well as a proposed fix.**** > > ** ** > > I see that George Shuklin made a commit to the code 3 months ago (see > https://github.com/xen-org/xen-api/commit/06c2d0fedc7031c27ad9215a751c404fde1ebb70 > ) > that made changes to the script regarding this feature, but my tests have > shown that this change is insufficient to handle all use cases.**** > > ** ** > > When attempting to use the port-locking features on a VIF that is > connected to a "normal" network (no VLAN tags), the logic works correctly. > However, It breaks when a VLAN-tagged network comes into play. What > happens is that the VLAN network is added to the network as a "fake > bridge," to use the vSwitch terminology, which is a child object to the > primary bridge device. When a VIF is attached to the (VLAN-tagged) > network, it is associated with this fake bridge instead of the real bridge. > So, when this script is called against such a VIF, the > get_bridge_name_vswitch() function returns the name of the fake bridge > instead of the real one.**** > > ** ** > > The problem is that most of the ovs-* Open vSwitch utilities, including > the ovs-ofctl that is used to set up the VIF filters, don't recognize the > fake bridge as a valid bridge device and fail, and the port locking rules > never get added. Also, the way this script is written, these failures are > silent because the return code is not captured, but I have not done > anything about that.**** > > ** ** > > I have tested a fix that appears to work in both the VLAN and the non-VLAN > case. Roughly described, after getting a bridge device name by executing > "ovs-vsctl iface-to-br vif_name", I run "ovs-vsctl br-to-parent > bridge_device" and return that instead. If the bridge device is a fake > bridge, it returns the "real" bridge device name, but if it is already a > real bridge device, it returns the same device name that was passed as a > parameter.**** > > ** ** > > I am somewhat unfamiliar with the process for contributing bug fixes to an > open source project (if this fix is accepted, it will be my first!), and I > am also pretty new to git (I've used other source control systems, though). > What is the best way for me to provide my suggested fix? Should I post > the .diff here on the mailing list? Should I create a pull request from my > own fork of the xen-api repository on github that has the suggested code > changes?**** > > ** ** > > Thanks in advance,**** > > ** ** > > Kevin Tower**** >
_______________________________________________ Xen-api mailing list [email protected] http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
