Re: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation
Hi Alin, I don't see a big value from this patch if I understand it correctly. Firstly, your commit is not clear about what it means when it says "typing it later on". Are you referring to typing it later on in the documentation? Secondly, since Hyper-V has different switch types such as "internal", "external", "private", replacing the switch name in the documentation with "external" might confuse readers unnecessarily, since its also a type. If you want to rename it, you could just call it something like "ovsext-switch" or just "ovsext". Please find the other comments inline. Thanks, Shashank From: ovs-dev-boun...@openvswitch.org on behalf of Alin Serdean Sent: Saturday, February 4, 2017 12:21 AM To: d...@openvswitch.org Subject: [ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation Use shorter name for the Hyper-V vSwitch for simplicity of typing it later on. Signed-off-by: Alin Gabriel Serdean --- Documentation/intro/install/windows.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst index ece207d..2341b5c 100644 --- a/Documentation/intro/install/windows.rst +++ b/Documentation/intro/install/windows.rst @@ -274,12 +274,12 @@ Enforcement' during boot. The following commands can be used: In the Virtual Switch Manager configuration you can enable the Open vSwitch Extension on an existing switch or create a new switch. -The command to create a new switch named 'OVS-Extended-Switch' using a physical -NIC named 'Ethernet0' is: +The command to create a new switch named 'external' using a physical NIC named +'Ethernet0' is: .. code-block:: ps1con - PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" ` + PS > New-VMSwitch external -NetAdapterName "Ethernet0" ` -AllowManagementOS $false [SR]: The commit msgh does not mention anything about the "AllowManagementOS" flag being added. What's the reason for this? .. note:: @@ -293,7 +293,7 @@ An alternative way to do the same is to run the following command: .. code-block:: ps1con - PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch + PS > Enable-VMSwitchExtension "Open vSwitch Extension" external .. note:: -- 2.10.2.windows.1 ___ dev mailing list d...@openvswitch.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=6OuVHk-mnufSWzkKa74UkQ&m=ANt1MyWGWPCfbl8o7d8EK5wC138sS4Uuzm8XX4IsouA&s=WtqG4fs_RRxuNxJrrZZ7cK19KcdlqwhuzYpesaRapeE&e= ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] rhel: Fix firewalld additions.
When I updated this patch for v2, I made some mistakes. This fixes them.
The first is that we need to create a directory in the rpm build root for
the firewalld service files before we can install them there. Second,
I made two typos when I updated the patch to use %{_prefix}.
Fixes: 55f36be59122 ("rhel: Firewall service files for OVN.")
Signed-off-by: Russell Bryant
---
rhel/openvswitch-fedora.spec.in | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
I already applied this to master and branch-2.7 as the fixes are obvious enough.
The "install" command was in v1 and it got lost when I adapted it for v2.
The other two changes are obvious typos.
diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index 262acd0..1173ade 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -234,6 +234,7 @@ touch
$RPM_BUILD_ROOT%{_sysconfdir}/openvswitch/system-id.conf
install -p -m 644 -D selinux/openvswitch-custom.pp \
$RPM_BUILD_ROOT%{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp
+install -d $RPM_BUILD_ROOT%{_prefix}/lib/firewalld/services/
install rhel/usr_lib_firewalld_services_ovn-central-firewall-service.xml \
$RPM_BUILD_ROOT%{_prefix}/lib/firewalld/services/ovn-central-firewall-service.xml
install rhel/usr_lib_firewalld_services_ovn-host-firewall-service.xml \
@@ -524,13 +525,13 @@ fi
%config %{_datadir}/openvswitch/ovn-nb.ovsschema
%config %{_datadir}/openvswitch/ovn-sb.ovsschema
%{_unitdir}/ovn-northd.service
-${_prefix}/lib/firewalld/services/ovn-central-firewall-service.xml
+%{_prefix}/lib/firewalld/services/ovn-central-firewall-service.xml
%files ovn-host
%{_bindir}/ovn-controller
%{_mandir}/man8/ovn-controller.8*
%{_unitdir}/ovn-controller.service
-${_prefix}/lib/firewalld/services/ovn-host-firewall-service.xml
+%{_prefix}/lib/firewalld/services/ovn-host-firewall-service.xml
%files ovn-vtep
%{_bindir}/ovn-controller-vtep
--
2.9.3
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] windows: automake.mk: Remove the .gitignore file from distributed files
Commit d183efc22b2b ("This commit adds the windows installer to the
OVS tree.) added the .gitignore file to the distributed files but this
file shouldn't be part of the distributed archive.
Cc: Alin Gabriel Serdean
Signed-off-by: Markos Chandras
---
windows/automake.mk | 1 -
1 file changed, 1 deletion(-)
diff --git a/windows/automake.mk b/windows/automake.mk
index db2b61639..4fec99ed9 100644
--- a/windows/automake.mk
+++ b/windows/automake.mk
@@ -38,7 +38,6 @@ windows_installer: all
MSBuild.exe windows/ovs-windows-installer.sln /target:Build
/property:Configuration="Release" /property:Version="$(PACKAGE_VERSION)"
EXTRA_DIST += \
- windows/.gitignore \
windows/automake.mk \
windows/README.rst \
windows/ovs-windows-installer.sln \
--
2.11.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [BUG] upcall handler thread crash
Hi, what’s the OvS version you tested. I didn’t get the crash with master
version.
The test script is described as below.
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth1
for i in `seq 0 1000`;
do
ovs-vsctl add-port br0 eth2
ovs-vsctl del-port br0 eth2
done
Thanks.
Nick
> On Feb 4, 2017, at 7:21 PM, wangyunjian wrote:
>
> Recently, write a script add and delete port repeatly, ovs upcall handler
> thread crash with the following trace.
> In the code bellow, weather the operations of mbridge->mbundles hmap should
> with a lock to protect content between ovs-vswichd thread and the upcall
> handler thread:
>
> static struct mbundle *
> mbundle_lookup(const struct mbridge *mbridge, struct ofbundle *ofbundle)
> {
>struct mbundle *mbundle;
>
>HMAP_FOR_EACH_IN_BUCKET (mbundle, hmap_node, hash_pointer(ofbundle, 0),
> &mbridge->mbundles) {
>if (mbundle->ofbundle == ofbundle) {
>return mbundle;
>}
>}
>return NULL;
> }
>
> Call Trace:
> #0 0x0044d838 in mbundle_lookup (mbridge=0x7fbf68000cc0,
> ofbundle=0x7fbf7007c3d0) at ofproto/ofproto_dpif_mirror.c:472
> #1 0x0044da15 in mirror_bundle_out (mbridge=,
> ofbundle=) at ofproto/ofproto_dpif_mirror.c:192
> #2 0x00448658 in xbundle_mirror_out (xbridge=0x7fbf5c6468a0,
> xbundle=0x7fbf3d48a160) at ofproto/ofproto_dpif_xlate.c:1556
> #3 xlate_normal_flood (ctx=ctx@entry=0x7fbf7729e3d0,
> in_xbundle=in_xbundle@entry=0x7fbf5c22f870, vlan=vlan@entry=100) at
> ofproto/ofproto_dpif_xlate.c:2525
> #4 0x00448e7e in xlate_normal (ctx=0x7fbf7729e3d0) at
> ofproto/ofproto_dpif_xlate.c:2724
> #5 xlate_output_action (ctx=ctx@entry=0x7fbf7729e3d0, port=,
> max_len=, may_packet_in=may_packet_in@entry=true) at
> ofproto/ofproto_dpif_xlate.c:4061
> #6 0x00445147 in do_xlate_actions (ofpacts=0x6eb7288, ofpacts_len=16,
> ctx=ctx@entry=0x7fbf7729e3d0) at ofproto/ofproto_dpif_xlate.c:4616
> #7 0x00446481 in xlate_recursively (rule=0x6eb7100,
> ctx=0x7fbf7729e3d0) at ofproto/ofproto_dpif_xlate.c:3445
> #8 xlate_table_action (ctx=0x7fbf7729e3d0, in_port=,
> table_id=, may_packet_in=,
> honor_table_miss=) at ofproto/ofproto_dpif_xlate.c:3513
> #9 0x004475a2 in compose_output_action__
> (ctx=ctx@entry=0x7fbf7729e3d0, ofp_port=, xr=,
> check_stp=check_stp@entry=true) at ofproto/ofproto_dpif_xlate.c:3206
> #10 0x00447bbf in compose_output_action (xr=,
> ofp_port=, ctx=0x7fbf7729e3d0) at
> ofproto/ofproto_dpif_xlate.c:3426
> #11 output_normal (ctx=ctx@entry=0x7fbf7729e3d0,
> out_xbundle=out_xbundle@entry=0x7fbf5cdf4aa0, vlan=vlan@entry=0) at
> ofproto/ofproto_dpif_xlate.c:2073
> #12 0x004486ae in xlate_normal_flood (ctx=ctx@entry=0x7fbf7729e3d0,
> in_xbundle=in_xbundle@entry=0x7fbf5e1d44d0, vlan=vlan@entry=0) at
> ofproto/ofproto_dpif_xlate.c:2529
> #13 0x00448e7e in xlate_normal (ctx=0x7fbf7729e3d0) at
> ofproto/ofproto_dpif_xlate.c:2724
> #14 xlate_output_action (ctx=ctx@entry=0x7fbf7729e3d0, port=,
> max_len=, may_packet_in=may_packet_in@entry=true) at
> ofproto/ofproto_dpif_xlate.c:4061
> #15 0x00445147 in do_xlate_actions
> (ofpacts=ofpacts@entry=0x7fbf70005ae8, ofpacts_len=ofpacts_len@entry=8,
> ctx=ctx@entry=0x7fbf7729e3d0) at ofproto/ofproto_dpif_xlate.c:4616
> #16 0x0044a739 in xlate_actions (xin=xin@entry=0x7fbf7729f570,
> xout=xout@entry=0x7fbf772c0b18) at ofproto/ofproto_dpif_xlate.c:5509
> #17 0x0043e4b6 in upcall_xlate (wc=0x7fbf772c0b70,
> odp_actions=0x7fbf772c0b30, upcall=0x7fbf772c0ac0, udpif=0x6e164a0) at
> ofproto/ofproto_dpif_upcall.c:1082
> #18 process_upcall (udpif=udpif@entry=0x6e164a0,
> upcall=upcall@entry=0x7fbf772c0ac0,
> odp_actions=odp_actions@entry=0x7fbf772c0b30, wc=wc@entry=0x7fbf772c0b70) at
> ofproto/ofproto_dpif_upcall.c:1220
> #19 0x004407d3 in recv_upcalls (handler=0x7fbf58944810,
> handler=0x7fbf58944810) at ofproto/ofproto_dpif_upcall.c:784
> #20 0x00440cca in udpif_upcall_handler (arg=0x7fbf58944810) at
> ofproto/ofproto_dpif_upcall.c:701
> #21 0x004c95e4 in ovsthread_wrapper (aux_=) at
> lib/ovs_thread.c:649
> #22 0x7fbf7aeaedc5 in start_thread () from /usr/lib64/libpthread.so.0
> #23 0x7fbf79a5e71d in clone () from /usr/lib64/libc.so.6
>
> #0 0x0044d838 in mbundle_lookup (mbridge=0x7fbf68000cc0,
> ofbundle=0x7fbf7007c3d0)
> 472 if (mbundle->ofbundle == ofbundle) {
> (gdb) p mbundle
> $1 = (struct mbundle *) 0x31
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] how to pars packets to layer 7
Hello all I 'm totally new in OVS. I want my open flow virtual switch to pars the packets of a specific protocol to the application layer. I want to extract some information of the packets. Is there any way in the OVS to do that? any modules should be modified?! Or may be I should use a dpi alongside of the OVS? if so, how to make them communicate with each other? Thank you in advance ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [BUG] upcall handler thread crash
Recently, write a script add and delete port repeatly, ovs upcall handler
thread crash with the following trace.
In the code bellow, weather the operations of mbridge->mbundles hmap should
with a lock to protect content between ovs-vswichd thread and the upcall
handler thread:
static struct mbundle *
mbundle_lookup(const struct mbridge *mbridge, struct ofbundle *ofbundle)
{
struct mbundle *mbundle;
HMAP_FOR_EACH_IN_BUCKET (mbundle, hmap_node, hash_pointer(ofbundle, 0),
&mbridge->mbundles) {
if (mbundle->ofbundle == ofbundle) {
return mbundle;
}
}
return NULL;
}
Call Trace:
#0 0x0044d838 in mbundle_lookup (mbridge=0x7fbf68000cc0,
ofbundle=0x7fbf7007c3d0) at ofproto/ofproto_dpif_mirror.c:472
#1 0x0044da15 in mirror_bundle_out (mbridge=,
ofbundle=) at ofproto/ofproto_dpif_mirror.c:192
#2 0x00448658 in xbundle_mirror_out (xbridge=0x7fbf5c6468a0,
xbundle=0x7fbf3d48a160) at ofproto/ofproto_dpif_xlate.c:1556
#3 xlate_normal_flood (ctx=ctx@entry=0x7fbf7729e3d0,
in_xbundle=in_xbundle@entry=0x7fbf5c22f870, vlan=vlan@entry=100) at
ofproto/ofproto_dpif_xlate.c:2525
#4 0x00448e7e in xlate_normal (ctx=0x7fbf7729e3d0) at
ofproto/ofproto_dpif_xlate.c:2724
#5 xlate_output_action (ctx=ctx@entry=0x7fbf7729e3d0, port=,
max_len=, may_packet_in=may_packet_in@entry=true) at
ofproto/ofproto_dpif_xlate.c:4061
#6 0x00445147 in do_xlate_actions (ofpacts=0x6eb7288, ofpacts_len=16,
ctx=ctx@entry=0x7fbf7729e3d0) at ofproto/ofproto_dpif_xlate.c:4616
#7 0x00446481 in xlate_recursively (rule=0x6eb7100, ctx=0x7fbf7729e3d0)
at ofproto/ofproto_dpif_xlate.c:3445
#8 xlate_table_action (ctx=0x7fbf7729e3d0, in_port=,
table_id=, may_packet_in=,
honor_table_miss=) at ofproto/ofproto_dpif_xlate.c:3513
#9 0x004475a2 in compose_output_action__ (ctx=ctx@entry=0x7fbf7729e3d0,
ofp_port=, xr=, check_stp=check_stp@entry=true)
at ofproto/ofproto_dpif_xlate.c:3206
#10 0x00447bbf in compose_output_action (xr=,
ofp_port=, ctx=0x7fbf7729e3d0) at
ofproto/ofproto_dpif_xlate.c:3426
#11 output_normal (ctx=ctx@entry=0x7fbf7729e3d0,
out_xbundle=out_xbundle@entry=0x7fbf5cdf4aa0, vlan=vlan@entry=0) at
ofproto/ofproto_dpif_xlate.c:2073
#12 0x004486ae in xlate_normal_flood (ctx=ctx@entry=0x7fbf7729e3d0,
in_xbundle=in_xbundle@entry=0x7fbf5e1d44d0, vlan=vlan@entry=0) at
ofproto/ofproto_dpif_xlate.c:2529
#13 0x00448e7e in xlate_normal (ctx=0x7fbf7729e3d0) at
ofproto/ofproto_dpif_xlate.c:2724
#14 xlate_output_action (ctx=ctx@entry=0x7fbf7729e3d0, port=,
max_len=, may_packet_in=may_packet_in@entry=true) at
ofproto/ofproto_dpif_xlate.c:4061
#15 0x00445147 in do_xlate_actions
(ofpacts=ofpacts@entry=0x7fbf70005ae8, ofpacts_len=ofpacts_len@entry=8,
ctx=ctx@entry=0x7fbf7729e3d0) at ofproto/ofproto_dpif_xlate.c:4616
#16 0x0044a739 in xlate_actions (xin=xin@entry=0x7fbf7729f570,
xout=xout@entry=0x7fbf772c0b18) at ofproto/ofproto_dpif_xlate.c:5509
#17 0x0043e4b6 in upcall_xlate (wc=0x7fbf772c0b70,
odp_actions=0x7fbf772c0b30, upcall=0x7fbf772c0ac0, udpif=0x6e164a0) at
ofproto/ofproto_dpif_upcall.c:1082
#18 process_upcall (udpif=udpif@entry=0x6e164a0,
upcall=upcall@entry=0x7fbf772c0ac0,
odp_actions=odp_actions@entry=0x7fbf772c0b30, wc=wc@entry=0x7fbf772c0b70) at
ofproto/ofproto_dpif_upcall.c:1220
#19 0x004407d3 in recv_upcalls (handler=0x7fbf58944810,
handler=0x7fbf58944810) at ofproto/ofproto_dpif_upcall.c:784
#20 0x00440cca in udpif_upcall_handler (arg=0x7fbf58944810) at
ofproto/ofproto_dpif_upcall.c:701
#21 0x004c95e4 in ovsthread_wrapper (aux_=) at
lib/ovs_thread.c:649
#22 0x7fbf7aeaedc5 in start_thread () from /usr/lib64/libpthread.so.0
#23 0x7fbf79a5e71d in clone () from /usr/lib64/libc.so.6
#0 0x0044d838 in mbundle_lookup (mbridge=0x7fbf68000cc0,
ofbundle=0x7fbf7007c3d0)
472 if (mbundle->ofbundle == ofbundle) {
(gdb) p mbundle
$1 = (struct mbundle *) 0x31
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] S
Can we talk ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] S
Can we talk ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 4/4] doc-windows: Consolidate switch names in documentation
Use shorter name for the Hyper-V vSwitch for simplicity of typing it later on. Signed-off-by: Alin Gabriel Serdean --- Documentation/intro/install/windows.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst index ece207d..2341b5c 100644 --- a/Documentation/intro/install/windows.rst +++ b/Documentation/intro/install/windows.rst @@ -274,12 +274,12 @@ Enforcement' during boot. The following commands can be used: In the Virtual Switch Manager configuration you can enable the Open vSwitch Extension on an existing switch or create a new switch. -The command to create a new switch named 'OVS-Extended-Switch' using a physical -NIC named 'Ethernet0' is: +The command to create a new switch named 'external' using a physical NIC named +'Ethernet0' is: .. code-block:: ps1con - PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" ` + PS > New-VMSwitch external -NetAdapterName "Ethernet0" ` -AllowManagementOS $false .. note:: @@ -293,7 +293,7 @@ An alternative way to do the same is to run the following command: .. code-block:: ps1con - PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch + PS > Enable-VMSwitchExtension "Open vSwitch Extension" external .. note:: -- 2.10.2.windows.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/4] doc-windows: Remove obsolete documentation
Hard dependancy on default internal port (AllowManagementOS) has been removed. Software checksums are part of the windows datapath. Disconnecting/Connecting the VIF is no longer required. Unit tests are enabled and passing for some time now... The option to create a MSI has been added. Signed-off-by: Alin Gabriel Serdean --- Documentation/intro/install/windows.rst | 50 + 1 file changed, 13 insertions(+), 37 deletions(-) diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst index caa9f40..1e7707f 100644 --- a/Documentation/intro/install/windows.rst +++ b/Documentation/intro/install/windows.rst @@ -117,21 +117,6 @@ The following explains the steps in some detail. under Bash. The remainder, prefixed by ``>``, are PowerShell commands and must be run in PowerShell. -Install Requirements - - -* Share network adaptors - - We require that you don't disable the "Allow management operating system to - share this network adapter" under 'Virtual Switch Properties' > 'Connection - type: External network', in the HyperV virtual network switch configuration. - -* Checksum Offloads - - While there is some support for checksum/segmentation offloads in software, - this is still a work in progress. Till the support is complete we recommend - disabling TX/RX offloads for both the VM's as well as the HyperV. - Bootstrapping - @@ -287,16 +272,15 @@ Enforcement' during boot. The following commands can be used: You may have to restart the machine for the settings to take effect. In the Virtual Switch Manager configuration you can enable the Open vSwitch -Extension on an existing switch or create a new switch. If you are using an -existing switch, make sure to enable the "Allow Management OS" option for VXLAN -to work (covered later). +Extension on an existing switch or create a new switch. The command to create a new switch named 'OVS-Extended-Switch' using a physical NIC named 'Ethernet 1' is: .. code-block:: ps1con - PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1" + PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1" ` + -AllowManagementOS $false .. note:: @@ -517,22 +501,17 @@ assign a 'OVS port name' which is a unique name across all VIFs on this Hyper-V. The next step is to add the VIF to the ovsdb using its 'OVS port name' as key. -First, assign a unique 'OVS port name' to the VIF. The VIF needs to have been -disconnected from the Hyper-V switch before assigning a 'OVS port name' to it. -In the example below, we assign a 'OVS port name' called ``ovs-port-a`` to a -VIF on a VM ``VM1``. By using index 0 for ``$vnic``, the first VIF of the VM -is being addressed. After assigning the name ``ovs-port-a``, the VIF is -connected back to the Hyper-V switch with name ``OVS-HV-Switch``, which is -assumed to be the Hyper-V switch with OVS extension enabled.: +First, assign a unique 'OVS port name' to the VIF. In the example below, we +assign a 'OVS port name' called ``ovs-port-a`` to a VIF on a VM ``VM1``. By +using index 0 for ``$vnic``, the first VIF of the VM is being addressed. We +assume that OVS extension is enabled on the Hyper-V vSwitch to which the VIF is +connected: .. code-block:: ps1con PS > import-module .\datapath-windows\misc\OVS.psm1 PS > $vnic = Get-VMNetworkAdapter - PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a - PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \ - -SwitchName OVS-Extended-Switch Next, add the VIFs to ``br-int``: @@ -556,8 +535,6 @@ Dumping the ports should show the additional ports that were just added: > ovs-vsctl show 4cd86499-74df-48bd-a64d-8d115b12a9f2 Bridge br-pif - Port "vEthernet (external)" - Interface "vEthernet (external)" Port "Ethernet0" Interface "Ethernet0" Port br-pif @@ -677,9 +654,9 @@ Re-Add the VIF ports with the VLAN tag: Add tunnels ~~~ -The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add -tunnels. For example, first add the tunnel port between 172.168.201.101 <-> -172.168.201.102: +Let us add tunnels between two endpoints. +For example, first add the tunnel port between +172.168.201.101 <-> 172.168.201.102: .. code-block:: doscon @@ -791,9 +768,8 @@ his development repository in github and triggering a new build. TODO -* Investigate the working of sFlow on Windows and re-enable the unit tests. +* Investigate the working of sFlow on Windows. * Investigate and add the feature to provide QoS. -* Sign the driver & create an MSI for installing the different OpenvSwitch - components on Windows. +* Sign the driver -- 2.10.2.windows.1 ___ dev mailing list d...@openvsw
[ovs-dev] [PATCH 3/4] doc-windows: Consolidate the name of physical adapters
At the beginning of the document we talk about the NIC 'Ethernet 1'
after 'Ethernet0', followed by 'Ethernet0 2'.
Although just names it seems better to have a single way of defining them:
'Ethernet(*)'
Signed-off-by: Alin Gabriel Serdean
---
Documentation/intro/install/windows.rst | 40 -
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/Documentation/intro/install/windows.rst
b/Documentation/intro/install/windows.rst
index 341b975..ece207d 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -275,11 +275,11 @@ In the Virtual Switch Manager configuration you can
enable the Open vSwitch
Extension on an existing switch or create a new switch.
The command to create a new switch named 'OVS-Extended-Switch' using a physical
-NIC named 'Ethernet 1' is:
+NIC named 'Ethernet0' is:
.. code-block:: ps1con
- PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1" `
+ PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet0" `
-AllowManagementOS $false
.. note::
@@ -556,8 +556,8 @@ found at technet_.
.. _technet:
https://technet.microsoft.com/en-us/library/jj553812%28v=wps.630%29.aspx
-For example, to set up a switch team combined from ``Ethernet0 2`` and
-``Ethernet1 2`` named ``external``:
+For example, to set up a switch team combined from ``Ethernet0`` and
+``Ethernet1`` named ``external``:
.. code-block:: ps1con
@@ -566,16 +566,16 @@ For example, to set up a switch team combined from
``Ethernet0 2`` and
br-intHyper-V Virtual Ethernet Adapter #3
br-pifHyper-V Virtual Ethernet Adapter #2
- Ethernet3 2 Intel(R) 82574L Gigabit Network Co...#3
- Ethernet2 2 Intel(R) 82574L Gigabit Network Co...#4
- Ethernet1 2 Intel(R) 82574L Gigabit Network Co...#2
- Ethernet0 2 Intel(R) 82574L Gigabit Network Conn...
+ Ethernet3 Intel(R) 82574L Gigabit Network Co...#3
+ Ethernet2 Intel(R) 82574L Gigabit Network Co...#4
+ Ethernet1 Intel(R) 82574L Gigabit Network Co...#2
+ Ethernet0 Intel(R) 82574L Gigabit Network Conn...
- PS > New-NetSwitchTeam -Name external -TeamMembers "Ethernet0 2","Ethernet1
2"
+ PS > New-NetSwitchTeam -Name external -TeamMembers "Ethernet0","Ethernet1"
PS > Get-NetSwitchTeam
Name: external
- Members : {Ethernet1 2, Ethernet0 2}
+ Members : {Ethernet1, Ethernet0}
This will result in a new adapter bound to the host called ``external``:
@@ -587,10 +587,10 @@ This will result in a new adapter bound to the host
called ``external``:
br-test Hyper-V Virtual Ethernet Adapter #4
br-pifHyper-V Virtual Ethernet Adapter #2
external Microsoft Network Adapter Multiplexo...
- Ethernet3 2 Intel(R) 82574L Gigabit Network Co...#3
- Ethernet2 2 Intel(R) 82574L Gigabit Network Co...#4
- Ethernet1 2 Intel(R) 82574L Gigabit Network Co...#2
- Ethernet0 2 Intel(R) 82574L Gigabit Network Conn...
+ Ethernet3 Intel(R) 82574L Gigabit Network Co...#3
+ Ethernet2 Intel(R) 82574L Gigabit Network Co...#4
+ Ethernet1 Intel(R) 82574L Gigabit Network Co...#2
+ Ethernet0 Intel(R) 82574L Gigabit Network Conn...
Next we will set up the Hyper-V VMSwitch on the new adapter ``external``:
@@ -599,8 +599,8 @@ Next we will set up the Hyper-V VMSwitch on the new adapter
``external``:
PS > New-VMSwitch -Name external -NetAdapterName external \
-AllowManagementOS $false
-Under OVS the adapters under the team ``external``, ``Ethernet0 2`` and
-``Ethernet1 2``, can be added either under a bond device or separately.
+Under OVS the adapters under the team ``external``, ``Ethernet0`` and
+``Ethernet1``, can be added either under a bond device or separately.
The following example shows how the bridges look with the NICs being
separated:
@@ -613,11 +613,11 @@ separated:
Port br-test
Interface br-test
type: internal
- Port "Ethernet1 2"
- Interface "Ethernet1 2"
+ Port "Ethernet1"
+ Interface "Ethernet1"
Bridge br-pif
- Port "Ethernet0 2"
- Interface "Ethernet0 2"
+ Port "Ethernet0"
+ Interface "Ethernet0"
Port br-pif
Interface br-pif
type: internal
--
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/4] doc-windows: Update supported tunnel ports
Update the tunnel documentation as per: https://github.com/openvswitch/ovs/blob/master/Documentation/faq/releases.rst Using the following command: ovs-vsctl add-port br-int tun-2 will trigger an error because the type is not defined. Update the documentation to chain commands so the error will not scare users. Signed-off-by: Alin Gabriel Serdean --- Documentation/intro/install/windows.rst | 27 ++- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst index 1e7707f..341b975 100644 --- a/Documentation/intro/install/windows.rst +++ b/Documentation/intro/install/windows.rst @@ -660,25 +660,26 @@ For example, first add the tunnel port between .. code-block:: doscon - > ovs-vsctl add-port br-int tun-1 - > ovs-vsctl set Interface tun-1 type= - > ovs-vsctl set Interface tun-1 options:local_ip=172.168.201.101 - > ovs-vsctl set Interface tun-1 options:remote_ip=172.168.201.102 - > ovs-vsctl set Interface tun-1 options:in_key=flow - > ovs-vsctl set Interface tun-1 options:out_key=flow + > ovs-vsctl add-port br-int tun-1 \ + -- set Interface tun-1 type= \ + -- set Interface tun-1 options:local_ip=172.168.201.101 \ + -- set Interface tun-1 options:remote_ip=172.168.201.102 \ + -- set Interface tun-1 options:in_key=flow \ + -- set Interface tun-1 options:out_key=flow ...and the tunnel port between 172.168.201.101 <-> 172.168.201.105: .. code-block:: doscon - > ovs-vsctl add-port br-int tun-2 - > ovs-vsctl set Interface tun-2 type= - > ovs-vsctl set Interface tun-2 options:local_ip=172.168.201.102 - > ovs-vsctl set Interface tun-2 options:remote_ip=172.168.201.105 - > ovs-vsctl set Interface tun-2 options:in_key=flow - > ovs-vsctl set Interface tun-2 options:out_key=flow + > ovs-vsctl add-port br-int tun-2 \ + -- set Interface tun-2 type= \ + -- set Interface tun-2 options:local_ip=172.168.201.102 \ + -- set Interface tun-2 options:remote_ip=172.168.201.105 \ + -- set Interface tun-2 options:in_key=flow \ + -- set Interface tun-2 options:out_key=flow -Where is one of: ``stt`` or ``vxlan`` +Where is one of: ``geneve``, ``gre``, ``stt`` or ``vxlan`` +For limitations please view :doc:`/faq/releases` for more information. .. note:: -- 2.10.2.windows.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
