ack on that.
We actually using different antispoofing model (which allows subnets),
and we do 'br-to-parent'.
I just fix a most obvious bug in new source code, but not dig deeper.
PS 2 Citrix guys: There is many fixes to xapi and sripts (like this) for
XCP 1.6. I can see them in tampa-lcm and master branches. But how about
binary update to xapi.rpm? Will we again see a year and half without
fixes like it was to XCP 1.1?
On 30.04.2013 17:58, Kevin Tower wrote:
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]
<mailto:[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]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Kevin Tower
*Sent:* 30 April 2013 5:51 AM
*To:* [email protected] <mailto:[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
_______________________________________________
Xen-api mailing list
[email protected]
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
