Based on Waldi''s RFC at
http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html
To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf
or use
script=vif-openvswitch in the vif configuration.
Appears to do the right thing for PV and HVM guests (including tap devices)
and with stubdomains.
In order to support VLAN tagging and trunking the "bridge" specified
in the
configuration can have a special syntax, that is:
BRIDGE_NAME[.VLAN][:TRUNK,TRUNK]
e.g.
- xenbr0.99
add the VIF to VLAN99 on xenbr0
- xenbr0:99,100,101
add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101
Waldi, can you confirm if I have correctly reverse engineered the syntax from
the regexp please ;-)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: waldi@debian.org
---
tools/examples/xl.conf | 2 +-
tools/hotplug/Linux/Makefile | 1 +
tools/hotplug/Linux/vif-openvswitch | 99 +++++++++++++++++++++++++++++++++++
3 files changed, 101 insertions(+), 1 deletions(-)
create mode 100644 tools/hotplug/Linux/vif-openvswitch
diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf
index 9402c3f..625b1a4 100644
--- a/tools/examples/xl.conf
+++ b/tools/examples/xl.conf
@@ -9,7 +9,7 @@
#lockfile="/var/lock/xl"
# default vif script
-#vifscript="vif-bridge"
+vifscript="vif-openvswitch"
# default output format used by "xl list -l"
#output_format="json"
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 0605559..99bf87f 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -13,6 +13,7 @@ XENCOMMONS_SYSCONFIG = init.d/sysconfig.xencommons
XEN_SCRIPTS = network-bridge vif-bridge
XEN_SCRIPTS += network-route vif-route
XEN_SCRIPTS += network-nat vif-nat
+XEN_SCRIPTS += vif-openvswitch
XEN_SCRIPTS += vif2
XEN_SCRIPTS += vif-setup
XEN_SCRIPTS += block
diff --git a/tools/hotplug/Linux/vif-openvswitch
b/tools/hotplug/Linux/vif-openvswitch
new file mode 100644
index 0000000..53c2f50
--- /dev/null
+++ b/tools/hotplug/Linux/vif-openvswitch
@@ -0,0 +1,99 @@
+#!/bin/bash
+#===========================================================================+#
${XEN_SCRIPT_DIR}/vif-openvswitch
+#
+# Script for configuring a vif in openvswitch mode.
+# The hotplugging system will call this script if it is specified either in
+# the device configuration given to Xend, or the default Xend configuration
+# in ${XEN_CONFIG_DIR}/xend-config.sxp. If the script is specified in
+# neither of those places, then this script is the default.
+#
+# Usage:
+# vif-openvswitch (add|remove|online|offline)
+#
+# Environment vars:
+# vif vif interface name (required).
+# XENBUS_PATH path to this device''s details in the XenStore
(required).
+#
+# Read from the store:
+# bridge openvswitch to add the vif to (required).
+# ip list of IP networks for the vif, space-separated (optional).
+#
+# up:
+# Enslaves the vif interface to the bridge and adds iptables rules
+# for its ip addresses (if any).
+#
+# down:
+# Removes the vif interface from the bridge and removes the iptables
+# rules for its ip addresses (if any).
+#===========================================================================+
+dir=$(dirname "$0")
+. "$dir/vif-common.sh"
+
+openvswitch_external_id() {
+ local dev=$1
+ local key=$2
+ local value=$3
+
+ echo "-- set interface $dev
external-ids:\"$key\"=\"$value\""
+}
+
+openvswitch_external_id_all() {
+ local dev=$1
+ local frontend_id=$(xenstore_read "$XENBUS_PATH/frontend-id")
+ local vm_path=$(xenstore_read "/local/domain/${frontend_id}/vm")
+ local name=$(xenstore_read "${vm_path}/name")
+ openvswitch_external_id $dev "xen-vm-name" "$name"
+ local uuid=$(xenstore_read "${vm_path}/uuid")
+ openvswitch_external_id $dev "xen-vm-uuid" "$uuid"
+ local mac=$(xenstore_read "$XENBUS_PATH/mac")
+ openvswitch_external_id $dev "attached-mac" "$mac"
+}
+
+add_to_openvswitch () {
+ local dev=$1
+ local bridge="$(xenstore_read_default "$XENBUS_PATH/bridge"
"$bridge")"
+ local tag trunk
+
+ if [[ $bridge =~
^([^.:]+)(\.([[:digit:]]+))?(:([[:digit:]]+(:[[:digit:]]+)*))?$ ]]; then
+ bridge="${BASH_REMATCH[1]}"
+ tag="${BASH_REMATCH[3]}"
+ trunk="${BASH_REMATCH[5]//:/,}"
+ else
+ fatal "No valid bridge was specified"
+ fi
+
+ if [ $trunk ]; then
+ local trunk_arg="trunk=$trunk"
+ fi
+
+ if [ $tag ]; then
+ local tag_arg="tag=$tag"
+ fi
+
+ local vif_details="$(openvswitch_external_id_all $dev)"
+
+ ovs-vsctl --timeout=30 -- --if-exists del-port $dev -- add-port
"$bridge" $dev $tag_arg $trunk_arg $vif_details
+ ip link set $dev up
+}
+
+case "$command" in
+ add|online)
+ setup_virtual_bridge_port $dev
+ add_to_openvswitch $dev
+ ;;
+
+ offline)
+ ovs-vsctl --timeout=30 -- --if-exists del-port $dev
+ ;;
+esac
+
+if [ "$type_if" = vif ]; then
+ handle_iptable
+fi
+
+log debug "Successful vif-openvswitch $command for $dev."
+if [ "$type_if" = vif -a "$command" = "online" ];
then
+ success
+fi
--
1.7.2.5
On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote:> Based on Waldi''s RFC at > http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html > > To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use > script=vif-openvswitch in the vif configuration. > > Appears to do the right thing for PV and HVM guests (including tap devices) > and with stubdomains. > > In order to support VLAN tagging and trunking the "bridge" specified in the > configuration can have a special syntax, that is: > > BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] > > e.g. > - xenbr0.99 > add the VIF to VLAN99 on xenbr0 > - xenbr0:99,100,101 > add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 > > Waldi, can you confirm if I have correctly reverse engineered the syntax from > the regexp please ;-)I''ve done this as a Xen patch, but in principal this could also be maintained in the openvswitch tree (I''ve added their list to the CC, having forgotten it with the initial posting). Anyone have any strong preference for one home over the other? If we do go with the Xen tree then WRT the feature freeze, this can pretty obviously only break things if you enable it.> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > Cc: waldi@debian.org > --- > tools/examples/xl.conf | 2 +-This change was an unintentional artefact of my local testing, please ignore...> tools/hotplug/Linux/Makefile | 1 + > tools/hotplug/Linux/vif-openvswitch | 99 +++++++++++++++++++++++++++++++++++ > 3 files changed, 101 insertions(+), 1 deletions(-) > create mode 100644 tools/hotplug/Linux/vif-openvswitch > > diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf > index 9402c3f..625b1a4 100644 > --- a/tools/examples/xl.conf > +++ b/tools/examples/xl.conf > @@ -9,7 +9,7 @@ > #lockfile="/var/lock/xl" > > # default vif script > -#vifscript="vif-bridge" > +vifscript="vif-openvswitch" > > # default output format used by "xl list -l" > #output_format="json" > diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile > index 0605559..99bf87f 100644 > --- a/tools/hotplug/Linux/Makefile > +++ b/tools/hotplug/Linux/Makefile > @@ -13,6 +13,7 @@ XENCOMMONS_SYSCONFIG = init.d/sysconfig.xencommons > XEN_SCRIPTS = network-bridge vif-bridge > XEN_SCRIPTS += network-route vif-route > XEN_SCRIPTS += network-nat vif-nat > +XEN_SCRIPTS += vif-openvswitch > XEN_SCRIPTS += vif2 > XEN_SCRIPTS += vif-setup > XEN_SCRIPTS += block > diff --git a/tools/hotplug/Linux/vif-openvswitch b/tools/hotplug/Linux/vif-openvswitch > new file mode 100644 > index 0000000..53c2f50 > --- /dev/null > +++ b/tools/hotplug/Linux/vif-openvswitch > @@ -0,0 +1,99 @@ > +#!/bin/bash > +#===========================================================================> +# ${XEN_SCRIPT_DIR}/vif-openvswitch > +# > +# Script for configuring a vif in openvswitch mode. > +# The hotplugging system will call this script if it is specified either in > +# the device configuration given to Xend, or the default Xend configuration > +# in ${XEN_CONFIG_DIR}/xend-config.sxp. If the script is specified in > +# neither of those places, then this script is the default. > +# > +# Usage: > +# vif-openvswitch (add|remove|online|offline) > +# > +# Environment vars: > +# vif vif interface name (required). > +# XENBUS_PATH path to this device''s details in the XenStore (required). > +# > +# Read from the store: > +# bridge openvswitch to add the vif to (required). > +# ip list of IP networks for the vif, space-separated (optional). > +# > +# up: > +# Enslaves the vif interface to the bridge and adds iptables rules > +# for its ip addresses (if any). > +# > +# down: > +# Removes the vif interface from the bridge and removes the iptables > +# rules for its ip addresses (if any). > +#===========================================================================> + > +dir=$(dirname "$0") > +. "$dir/vif-common.sh" > + > +openvswitch_external_id() { > + local dev=$1 > + local key=$2 > + local value=$3 > + > + echo "-- set interface $dev external-ids:\"$key\"=\"$value\"" > +} > + > +openvswitch_external_id_all() { > + local dev=$1 > + local frontend_id=$(xenstore_read "$XENBUS_PATH/frontend-id") > + local vm_path=$(xenstore_read "/local/domain/${frontend_id}/vm") > + local name=$(xenstore_read "${vm_path}/name") > + openvswitch_external_id $dev "xen-vm-name" "$name" > + local uuid=$(xenstore_read "${vm_path}/uuid") > + openvswitch_external_id $dev "xen-vm-uuid" "$uuid" > + local mac=$(xenstore_read "$XENBUS_PATH/mac") > + openvswitch_external_id $dev "attached-mac" "$mac" > +} > + > +add_to_openvswitch () { > + local dev=$1 > + local bridge="$(xenstore_read_default "$XENBUS_PATH/bridge" "$bridge")" > + local tag trunk > + > + if [[ $bridge =~ ^([^.:]+)(\.([[:digit:]]+))?(:([[:digit:]]+(:[[:digit:]]+)*))?$ ]]; then > + bridge="${BASH_REMATCH[1]}" > + tag="${BASH_REMATCH[3]}" > + trunk="${BASH_REMATCH[5]//:/,}" > + else > + fatal "No valid bridge was specified" > + fi > + > + if [ $trunk ]; then > + local trunk_arg="trunk=$trunk" > + fi > + > + if [ $tag ]; then > + local tag_arg="tag=$tag" > + fi > + > + local vif_details="$(openvswitch_external_id_all $dev)" > + > + ovs-vsctl --timeout=30 -- --if-exists del-port $dev -- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details > + ip link set $dev up > +} > + > +case "$command" in > + add|online) > + setup_virtual_bridge_port $dev > + add_to_openvswitch $dev > + ;; > + > + offline) > + ovs-vsctl --timeout=30 -- --if-exists del-port $dev > + ;; > +esac > + > +if [ "$type_if" = vif ]; then > + handle_iptable > +fi > + > +log debug "Successful vif-openvswitch $command for $dev." > +if [ "$type_if" = vif -a "$command" = "online" ]; then > + success > +fi
On Thu, Apr 18, 2013 at 12:50:40PM +0100, Ian Campbell wrote:> Based on Waldi''s RFC at > http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html > BRIDGE_NAME[.VLAN][:TRUNK,TRUNK]This needs to be BRIDGE_NAME[.VLAN][:TRUNK:TRUNK]. "," is already taken as delimiter.> - xenbr0.99 > add the VIF to VLAN99 on xenbr0- xenbr0:99:100:101> add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101Bastian> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>Signed-off-by: Bastian Blank <waldi@debian.org>> diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf > index 9402c3f..625b1a4 100644 > --- a/tools/examples/xl.conf > +++ b/tools/examples/xl.conf > @@ -9,7 +9,7 @@ > #lockfile="/var/lock/xl" > > # default vif script > -#vifscript="vif-bridge" > +vifscript="vif-openvswitch"Do you really want to change the default in this patch? Bastian -- Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel", stardate 3842.3
(adding ovs list to this subthread too) On Thu, 2013-04-18 at 13:19 +0100, Bastian Blank wrote:> On Thu, Apr 18, 2013 at 12:50:40PM +0100, Ian Campbell wrote: > > Based on Waldi''s RFC at > > http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html > > BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] > > This needs to be BRIDGE_NAME[.VLAN][:TRUNK:TRUNK]. "," is already taken > as delimiter.Thanks -- I tested the regex in isolation in a test script and forgot that it was part of a larger syntax. I''ve adjusted the commit message.> > - xenbr0.99 > > add the VIF to VLAN99 on xenbr0 > - xenbr0:99:100:101 > > add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 > > Bastian > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > Signed-off-by: Bastian Blank <waldi@debian.org>Thanks!> > > diff --git a/tools/examples/xl.conf b/tools/examples/xl.conf > > index 9402c3f..625b1a4 100644 > > --- a/tools/examples/xl.conf > > +++ b/tools/examples/xl.conf > > @@ -9,7 +9,7 @@ > > #lockfile="/var/lock/xl" > > > > # default vif script > > -#vifscript="vif-bridge" > > +vifscript="vif-openvswitch" > > Do you really want to change the default in this patch?Nope, I called this out in my early reply-to-self as a mistake. Ian.
On Thu, Apr 18, 2013 at 12:50:40PM +0100, Ian Campbell wrote:> + ovs-vsctl --timeout=30 -- --if-exists del-port $dev -- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details > + ovs-vsctl --timeout=30 -- --if-exists del-port $devThere is some error handling missing. Not sure how to do that correctly. Bastian -- There''s a way out of any cage. -- Captain Christopher Pike, "The Menagerie" ("The Cage"), stardate unknown.
On Thu, 2013-04-18 at 14:42 +0100, Bastian Blank wrote:> On Thu, Apr 18, 2013 at 12:50:40PM +0100, Ian Campbell wrote: > > + ovs-vsctl --timeout=30 -- --if-exists del-port $dev -- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details > > + ovs-vsctl --timeout=30 -- --if-exists del-port $dev > > There is some error handling missing. Not sure how to do that correctly.Possibly should either call fatal on error or use the do_or_die helper?
On 18/04/13 13:08, Ian Campbell wrote:> On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote: >> Based on Waldi''s RFC at >> http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html >> >> To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use >> script=vif-openvswitch in the vif configuration. >> >> Appears to do the right thing for PV and HVM guests (including tap devices) >> and with stubdomains. >> >> In order to support VLAN tagging and trunking the "bridge" specified in the >> configuration can have a special syntax, that is: >> >> BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] >> >> e.g. >> - xenbr0.99 >> add the VIF to VLAN99 on xenbr0 >> - xenbr0:99,100,101 >> add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 >> >> Waldi, can you confirm if I have correctly reverse engineered the syntax from >> the regexp please ;-) > I''ve done this as a Xen patch, but in principal this could also be > maintained in the openvswitch tree (I''ve added their list to the CC, > having forgotten it with the initial posting). Anyone have any strong > preference for one home over the other? > > If we do go with the Xen tree then WRT the feature freeze, this can > pretty obviously only break things if you enable it.Sure; but we don''t want to have a bunch of shiny-looking new features that are in fact crappy and unreliable, just because they weren''t there before. :-) Just to be clear, I''m not saying this will be unreliable; it looks pretty simple and straightforward. I''m just saying we still need to consider whether we''ll find bugs before the release or not, even if it doesn''t break existing functionality. How about something like this: We add a warning in the script saying it''s tech-preview. When we start RC''s, I''ll write a blog specifically asking people to test it and give their feedback. If I get a certain number of people saying they''ve tested it on their systems and that it seems to work (10 or so?) then we can take the warning out and call it a plain feature. What do you think? -George
On Thu, 2013-04-18 at 17:07 +0100, George Dunlap wrote:> On 18/04/13 13:08, Ian Campbell wrote: > > On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote: > >> Based on Waldi''s RFC at > >> http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html > >> > >> To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use > >> script=vif-openvswitch in the vif configuration. > >> > >> Appears to do the right thing for PV and HVM guests (including tap devices) > >> and with stubdomains. > >> > >> In order to support VLAN tagging and trunking the "bridge" specified in the > >> configuration can have a special syntax, that is: > >> > >> BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] > >> > >> e.g. > >> - xenbr0.99 > >> add the VIF to VLAN99 on xenbr0 > >> - xenbr0:99,100,101 > >> add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 > >> > >> Waldi, can you confirm if I have correctly reverse engineered the syntax from > >> the regexp please ;-) > > I''ve done this as a Xen patch, but in principal this could also be > > maintained in the openvswitch tree (I''ve added their list to the CC, > > having forgotten it with the initial posting). Anyone have any strong > > preference for one home over the other? > > > > If we do go with the Xen tree then WRT the feature freeze, this can > > pretty obviously only break things if you enable it. > > Sure; but we don''t want to have a bunch of shiny-looking new features > that are in fact crappy and unreliable, just because they weren''t there > before. :-) > > Just to be clear, I''m not saying this will be unreliable; it looks > pretty simple and straightforward. I''m just saying we still need to > consider whether we''ll find bugs before the release or not, even if it > doesn''t break existing functionality. > > How about something like this: We add a warning in the script saying > it''s tech-preview. When we start RC''s, I''ll write a blog specifically > asking people to test it and give their feedback. If I get a certain > number of people saying they''ve tested it on their systems and that it > seems to work (10 or so?) then we can take the warning out and call it > a plain feature. > > What do you think?No one will ever see the output from the hotplug scripts so I think that''s a bit of a waste of time. We could call it out specifically in the call for testing for rc1 etc and position it as appropriate in the release notes based on the feedback we get. Ian.> > -George >
On 18/04/13 17:16, Ian Campbell wrote:> On Thu, 2013-04-18 at 17:07 +0100, George Dunlap wrote: >> On 18/04/13 13:08, Ian Campbell wrote: >>> On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote: >>>> Based on Waldi''s RFC at >>>> http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html >>>> >>>> To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use >>>> script=vif-openvswitch in the vif configuration. >>>> >>>> Appears to do the right thing for PV and HVM guests (including tap devices) >>>> and with stubdomains. >>>> >>>> In order to support VLAN tagging and trunking the "bridge" specified in the >>>> configuration can have a special syntax, that is: >>>> >>>> BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] >>>> >>>> e.g. >>>> - xenbr0.99 >>>> add the VIF to VLAN99 on xenbr0 >>>> - xenbr0:99,100,101 >>>> add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 >>>> >>>> Waldi, can you confirm if I have correctly reverse engineered the syntax from >>>> the regexp please ;-) >>> I''ve done this as a Xen patch, but in principal this could also be >>> maintained in the openvswitch tree (I''ve added their list to the CC, >>> having forgotten it with the initial posting). Anyone have any strong >>> preference for one home over the other? >>> >>> If we do go with the Xen tree then WRT the feature freeze, this can >>> pretty obviously only break things if you enable it. >> Sure; but we don''t want to have a bunch of shiny-looking new features >> that are in fact crappy and unreliable, just because they weren''t there >> before. :-) >> >> Just to be clear, I''m not saying this will be unreliable; it looks >> pretty simple and straightforward. I''m just saying we still need to >> consider whether we''ll find bugs before the release or not, even if it >> doesn''t break existing functionality. >> >> How about something like this: We add a warning in the script saying >> it''s tech-preview. When we start RC''s, I''ll write a blog specifically >> asking people to test it and give their feedback. If I get a certain >> number of people saying they''ve tested it on their systems and that it >> seems to work (10 or so?) then we can take the warning out and call it >> a plain feature. >> >> What do you think? > No one will ever see the output from the hotplug scripts so I think > that''s a bit of a waste of time. > > We could call it out specifically in the call for testing for rc1 etc > and position it as appropriate in the release notes based on the > feedback we get.Sure, sounds good. -George
On Thu, Apr 18, 2013 at 01:08:40PM +0100, Ian Campbell wrote:> On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote: > > Based on Waldi''s RFC at > > http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html > > > > To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use > > script=vif-openvswitch in the vif configuration. > > > > Appears to do the right thing for PV and HVM guests (including tap devices) > > and with stubdomains. > > > > In order to support VLAN tagging and trunking the "bridge" specified in the > > configuration can have a special syntax, that is: > > > > BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] > > > > e.g. > > - xenbr0.99 > > add the VIF to VLAN99 on xenbr0 > > - xenbr0:99,100,101 > > add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 > > > > Waldi, can you confirm if I have correctly reverse engineered the syntax from > > the regexp please ;-) > > I''ve done this as a Xen patch, but in principal this could also be > maintained in the openvswitch tree (I''ve added their list to the CC, > having forgotten it with the initial posting). Anyone have any strong > preference for one home over the other?It looks to me like the proposed script uses only Open vSwitch interfaces (via ovs-vsctl) that have been stable for a long time. My guess is that Xen users will be more likely to easily find this script if it is in the Xen distribution than if it is in the Open vSwitch one. So I would be inclined to believe that Xen is the right place for it. That said, we''d be happy to include it with OVS if you think the balance falls the other way. Thanks, Ben.
On Thu, 2013-04-18 at 19:01 +0100, Ben Pfaff wrote:> On Thu, Apr 18, 2013 at 01:08:40PM +0100, Ian Campbell wrote: > > On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote: > > > Based on Waldi''s RFC at > > > http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html > > > > > > To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use > > > script=vif-openvswitch in the vif configuration. > > > > > > Appears to do the right thing for PV and HVM guests (including tap devices) > > > and with stubdomains. > > > > > > In order to support VLAN tagging and trunking the "bridge" specified in the > > > configuration can have a special syntax, that is: > > > > > > BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] > > > > > > e.g. > > > - xenbr0.99 > > > add the VIF to VLAN99 on xenbr0 > > > - xenbr0:99,100,101 > > > add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 > > > > > > Waldi, can you confirm if I have correctly reverse engineered the syntax from > > > the regexp please ;-) > > > > I''ve done this as a Xen patch, but in principal this could also be > > maintained in the openvswitch tree (I''ve added their list to the CC, > > having forgotten it with the initial posting). Anyone have any strong > > preference for one home over the other? > > It looks to me like the proposed script uses only Open vSwitch > interfaces (via ovs-vsctl) that have been stable for a long time.I must confess it never even occurred to me to consider the stability of this interface, but thanks for considering it and confirming!> My > guess is that Xen users will be more likely to easily find this script > if it is in the Xen distribution than if it is in the Open vSwitch one. > So I would be inclined to believe that Xen is the right place for it. > > That said, we''d be happy to include it with OVS if you think the balance > falls the other way.I think you are correct in your guess. Lets take it into the Xen tree then. Thanks, Ian.