* Install the latest Python 2.x from python.org and verify that its path is
part of Windows' PATH environment variable.
-* You will need at least Visual Studio 2013 to compile userspace binaries. In
-addition to that, if you want to compile the kernel module you will also need to
-install Windows Driver Kit (WDK) 8.1 Update.
+* You will need at least Visual Studio 2013 (update 4) to compile userspace
+binaries. In addition to that, if you want to compile the kernel module you
+will also need to install Windows Driver Kit (WDK) 8.1 Update.
It is important to get the Visual Studio related environment variables and to
-have the $PATH inside the bash to point to the proper compiler and linker. One
-easy way to achieve this is to get into the "Developer Command prompt for visual
-studio" and through it enter into the bash shell available from msys by typing
+have the $PATH inside the bash to point to the proper compiler and linker. One
+easy way to achieve this for VS2013 is to get into the "VS2013 x86 Native
+Tools Command Prompt" (in a default installation of Visual Studio 2013 this can
+be found under the following location:
+C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts)
+and through it enter into the bash shell available from msys by typing
'bash --login'.
+There is support for generating 64 bit binaries too. To compile under x64,
+open the "VS2013 x64 Native Tools Command Prompt" (if your current running OS
+is 64 bit) or "VS2013 x64 Cross Tools Command Prompt" (if your current running
+OS is not 64 bit) instead of opening its x86 variant. This will point the
+compiler and the linker to their 64 bit equivalent.
+
If after the above step, a 'which link' inside MSYS's bash says,
"/bin/link.exe", rename /bin/link.exe to something else so that the
Visual studio's linker is used. You should also see a 'which sort' report
the right compiler, linker, libraries, Open vSwitch component installation
directories, etc. For example,
- % ./configure CC=./build-aux/cccl LD="`which link`" LIBS="-lws2_32" \
- --prefix="C:/openvswitch/usr" --localstatedir="C:/openvswitch/var" \
- --sysconfdir="C:/openvswitch/etc" --with-pthread="C:/pthread"
+ % ./configure CC=./build-aux/cccl LD="`which link`" \
+ LIBS="-lws2_32 -liphlpapi" --prefix="C:/openvswitch/usr" \
+ --localstatedir="C:/openvswitch/var" --sysconfdir="C:/openvswitch/etc" \
+ --with-pthread="C:/pthread"
By default, the above enables compiler optimization for fast code.
For default compiler optimization, pass the "--with-debug" configure
* While configuring the package, specify the OpenSSL directory path.
For example,
- % ./configure CC=./build-aux/cccl LD="`which link`" LIBS="-lws2_32" \
- --prefix="C:/openvswitch/usr" --localstatedir="C:/openvswitch/var" \
- --sysconfdir="C:/openvswitch/etc" --with-pthread="C:/pthread" \
- --enable-ssl --with-openssl="C:/OpenSSL-Win32"
+ % ./configure CC=./build-aux/cccl LD="`which link`" \
+ LIBS="-lws2_32 -liphlpapi" --prefix="C:/openvswitch/usr" \
+ --localstatedir="C:/openvswitch/var" --sysconfdir="C:/openvswitch/etc" \
+ --with-pthread="C:/pthread" --enable-ssl --with-openssl="C:/OpenSSL-Win32"
* Run make for the ported executables.
* The kernel datapath can be compiled from command line as well. The top
level 'make' will invoke building the kernel datapath, if the
-'--with-vstudioddk' argument is specified while configuring the package.
+'--with-vstudiotarget' argument is specified while configuring the package.
For example,
- % ./configure CC=./build-aux/cccl LD="`which link`" LIBS="-lws2_32" \
- --prefix="C:/openvswitch/usr" --localstatedir="C:/openvswitch/var" \
- --sysconfdir="C:/openvswitch/etc" --with-pthread="C:/pthread" \
- --enable-ssl --with-openssl="C:/OpenSSL-Win32" \
- --with-vstudioddk="<WDK to use>"
+ % ./configure CC=./build-aux/cccl LD="`which link`" \
+ LIBS="-lws2_32 -liphlpapi" --prefix="C:/openvswitch/usr" \
+ --localstatedir="C:/openvswitch/var" --sysconfdir="C:/openvswitch/etc" \
+ --with-pthread="C:/pthread" --enable-ssl \
+ --with-openssl="C:/OpenSSL-Win32" --with-vstudiotarget="<target type>"
- Possible values for "<WDK to use>" are:
- "Win8.1 Debug", "Win8.1 Release", "Win8 Debug" and "Win8 Release".
+ Possible values for "<target type>" are:
+ "Debug" and "Release"
Installing the Kernel module
----------------------------
02> Run ./install.cmd to insert the new one. For this to work you will have to
turn on TESTSIGNING boot option or 'Disable Driver Signature Enforcement'
-during boot.
+during boot. The following commands can be used:
+ % bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
+ % bcdedit /set TESTSIGNING ON
+ % bcdedit /set nointegritychecks ON
+
+Note: you may have to restart the machine for the settings to take effect.
03> 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
07> Add the physical NIC and the internal port to br-pif.
-In OVS for Hyper-V, we use 'external' as a special name to refer to the
-physical NICs connected to the Hyper-V switch. An index is added to this
-special name to refer to the particular physical NIC. Eg. 'external.1' refers
-to the first physical NIC on the Hyper-V switch.
+In OVS for Hyper-V, we use the name of the adapter on top of which the Hyper-V
+virtual switch was created, as a special name to refer to the physical NICs
+connected to the Hyper-V switch. I.e. let us suppose we created the Hyper-V
+virtual switch on top of the adapter named 'Ethernet0'. In OVS for Hyper-V, we
+use that name('Ethernet0') as a special name to refer to that adapter.
Note: Currently, we assume that the Hyper-V switch on which OVS extension is
enabled has a single physical NIC connected to it.
-Interal port is the virtual adapter created on the Hyper-V switch using the
+Internal port is the virtual adapter created on the Hyper-V switch using the
'AllowManagementOS' setting. This has already been setup while creating the
-switch using the instructions above. In OVS for Hyper-V, we use a 'internal'
-as a special name to refer to that adapter.
+switch using the instructions above. In OVS for Hyper-V, we use a the name of
+that specific adapter as a special name to refer to that adapter. By default it
+is created under the following rule "vEthernet (<name of the switch>)".
+
+As a whole example, if we issue the following in a powershell console:
+PS C:\package\binaries> Get-NetAdapter | select Name,MacAddress,InterfaceDescription
+
+Name MacAddress InterfaceDescription
+---- ---------- --------------------
+Ethernet1 00-0C-29-94-05-65 Intel(R) PRO/1000 MT Network Connection
+vEthernet (external) 00-0C-29-94-05-5B Hyper-V Virtual Ethernet Adapter #2
+Ethernet0 00-0C-29-94-05-5B Intel(R) PRO/1000 MT Network Connection #2
+
+PS C:\package\binaries> Get-VMSwitch
- % ovs-vsctl add-port br-pif external.1
- % ovs-vsctl add-port br-pif internal
+Name SwitchType NetAdapterInterfaceDescription
+---- ---------- ------------------------------
+external External Intel(R) PRO/1000 MT Network Connection #2
+
+
+We can see that we have a switch(external) created upon adapter name 'Ethernet0'
+with an internal port under name 'vEthernet (external)'. Thus resulting into the
+following ovs-vsctl commands
+
+ % ovs-vsctl add-port br-pif Ethernet0
+ % ovs-vsctl add-port br-pif "vEthernet (external)"
* Dumping the ports should show the additional ports that were just added.
Sample output shows up as follows:
system@ovs-system:
lookups: hit:0 missed:0 lost:0
flows: 0
- port 4: internal (internal) <<< 'AllowManagementOS' adapter on
- Hyper-V switch
+ port 4: vEthernet (external) (internal) <<< 'AllowManagementOS'
+ adapter on
+ Hyper-V switch
port 2: br-pif (internal)
- port 1: br-int (internal
- port 3: external.1 <<< Physical NIC
+ port 1: br-int (internal)
+ port 3: Ethernet0 <<< Physical NIC
% ovs-vsctl show
a56ec7b5-5b1f-49ec-a795-79f6eb63228b
Bridge br-pif
- Port internal
- Interface internal
+ Port "vEthernet (external)"
+ Interface "vEthernet (external)"
Port br-pif
Interface br-pif
type: internal
+ Port "Ethernet0"
+ Interface "Ethernet0"
Bridge br-int
- Port "external.1"
- Interface "external.1"
Port br-int
Interface br-int
type: internal
system@ovs-system:
lookups: hit:0 missed:0 lost:0
flows: 0
- port 4: internal (internal)
+ port 4: vEthernet (external) (internal)
port 5: ovs-port-a
port 2: br-pif (internal)
port 1: br-int (internal
- port 3: external.1
+ port 3: Ethernet0
% ovs-vsctl show
4cd86499-74df-48bd-a64d-8d115b12a9f2
Bridge br-pif
- Port internal
- Interface internal
- Port "external.1"
- Interface "external.1"
+ Port "vEthernet (external)"
+ Interface "vEthernet (external)"
+ Port "Ethernet0"
+ Interface "Ethernet0"
Port br-pif
Interface br-pif
type: internal
% ovs-vsctl add-port br-int ovs-port-a tag=900
% ovs-vsctl add-port br-int ovs-port-b tag=900
-Steps to add VXLAN tunnels
+Steps to add tunnels
--------------------------
-The Windows Open vSwitch implementation support VXLAN tunnels. To add VXLAN
+The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add
tunnels, the following steps serve as examples.
Note that, any patch ports created between br-int and br-pif MUST be beleted
-prior to adding VXLAN tunnels.
+prior to adding tunnels.
+
+01> Add the tunnel port between 172.168.201.101 <-> 172.168.201.102
+ % ovs-vsctl add-port br-int tun-1
+ % ovs-vsctl set Interface tun-1 type=port-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
-01> Add the vxlan port between 172.168.201.101 <-> 172.168.201.102
- % ovs-vsctl add-port br-int vxlan-1
- % ovs-vsctl set Interface vxlan-1 type=vxlan
- % ovs-vsctl set Interface vxlan-1 options:local_ip=172.168.201.101
- % ovs-vsctl set Interface vxlan-1 options:remote_ip=172.168.201.102
- % ovs-vsctl set Interface vxlan-1 options:in_key=flow
- % ovs-vsctl set Interface vxlan-1 options:out_key=flow
+02> Add the tunnel port between 172.168.201.101 <-> 172.168.201.105
+ % ovs-vsctl add-port br-int tun-2
+ % ovs-vsctl set Interface tun-2 type=port-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
-02> Add the vxlan port between 172.168.201.101 <-> 172.168.201.105
- % ovs-vsctl add-port br-int vxlan-2
- % ovs-vsctl set Interface vxlan-2 type=vxlan
- % ovs-vsctl set Interface vxlan-2 options:local_ip=172.168.201.102
- % ovs-vsctl set Interface vxlan-2 options:remote_ip=172.168.201.105
- % ovs-vsctl set Interface vxlan-2 options:in_key=flow
- % ovs-vsctl set Interface vxlan-2 options:out_key=flow
+ Where port-type is the string stt or vxlan
Requirements
* Create the ovsdb-server service and start it.
- % sc create ovsdb-server binpath="C:/Shares/openvswitch/ovsdb/ovsdb-server.exe C:/openvswitch/etc/openvswitch/conf.db -vfile:info --log-file --pidfile --remote=punix:db.sock --service --service-monitor"
+ % sc create ovsdb-server binpath="C:/openvswitch/usr/sbin/ovsdb-server.exe C:/openvswitch/etc/openvswitch/conf.db -vfile:info --log-file --pidfile --remote=punix:db.sock --service --service-monitor"
One of the common issues with creating a Windows service is with mungled
paths. You can make sure that the correct path has been registered with
* Create the ovs-vswitchd service and start it.
- % sc create ovs-vswitchd binpath="C:/Shares/openvswitch/vswitchd/ovs-vswitchd.exe --pidfile -vfile:info --log-file --service --service-monitor"
+ % sc create ovs-vswitchd binpath="C:/openvswitch/usr/sbin/ovs-vswitchd.exe --pidfile -vfile:info --log-file --service --service-monitor"
% sc start ovs-vswitchd
projects / cascardo / ovs.git / blobdiff