User Tools

Site Tools


ovs-hyperv-architecture

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ovs-hyperv-architecture [2014/06/23 03:20]
admin [C99]
ovs-hyperv-architecture [2014/06/23 03:39] (current)
Line 81: Line 81:
 OVS is written entirely in C, including the usage of C99 features. VS 2013 includes an array of additional C99 features previously not available that helped in easing the porting from a C language perspective. There are unfortunately still a few unsupported features that required workarounds. Most of these issues have been addressed in the Cloudbase port and subsequently in the OVS userspace code repository master branch thanks to community efforts. OVS is written entirely in C, including the usage of C99 features. VS 2013 includes an array of additional C99 features previously not available that helped in easing the porting from a C language perspective. There are unfortunately still a few unsupported features that required workarounds. Most of these issues have been addressed in the Cloudbase port and subsequently in the OVS userspace code repository master branch thanks to community efforts.
  
-  * “%zu” formatting missing in printf() and other standard library functions +  * //“%zu”// formatting missing in //printf()// and other standard library functions 
-  * snprintf() not available +  * //snprintf()// not available 
-  * #include_next not available +  * //#include_next// not available 
-  * gettimeofday() not available +  * //gettimeofday()// not available 
-  * Various minor #defines for constants and or function synonyms+  * Various minor //#defines// for constants and or function synonyms
  
-Features that required mapping to different APIs or alternative solutions+Features that required mapping to different APIs or alternative solutions:
  
   * Netlink interface not available. This is detailed in a separate paragraph further on.   * Netlink interface not available. This is detailed in a separate paragraph further on.
-  * Replace Unix sockets with TCP/IP, as this required the minimum set of changes in the codebase. Named pipes should be considered as well to increase performance.+  * Replace Unix sockets with TCP/IP, as this required the minimum set of changes in the codebase. Named pipes should be considered as well to improve performance.
   * SIGHUP, SIGINT and other signals are not available   * SIGHUP, SIGINT and other signals are not available
   * Map socket features to the WAS equivalents. poll() in particular is not available.   * Map socket features to the WAS equivalents. poll() in particular is not available.
   * Replace cryptographic routines with CryptoApi equivalents   * Replace cryptographic routines with CryptoApi equivalents
   * getopt not available   * getopt not available
-  * Linux daemons (ovs-vswitchd and ovsdb-server) need to be executed as Windows services +  * Linux daemons (//ovs-vswitchd// and //ovsdb-server//) need to be executed as Windows services 
  
 ===== Netlink replacement ===== ===== Netlink replacement =====
  
-Linux provides a socket based abstraction called Netlink to simplify user space / kernel communication. This feature is not available on Windows and has been replaced with the implementation of an ad hoc layer based on IoCreateDevice / CreateFile / ReadFile / WriteFile APIs. The user space part has been encapsulated in an API interface compatible with Netlink, to limit the amount of changes required in the OVS codebase. +Linux provides a socket based abstraction called Netlink to simplify user space / kernel communication. This feature is not available on Windows and has been replaced with the implementation of an ad hoc layer based on //IoCreateDevice / CreateFile / ReadFile / WriteFile// APIs. The user space part has been encapsulated in an API interface semantically identical to Netlink, to limit the amount of changes required in the OVS codebase. 
  
 Kernel: Kernel:
Line 105: Line 105:
 {{:ovs2.png?600|}} {{:ovs2.png?600|}}
  
-User space (ovs-vswitchd and ovs-dpctl): +User space (//ovs-vswitchd// and //ovs-dpctl//): 
  
 {{:ovs3.png?600|}} {{:ovs3.png?600|}}
Line 119: Line 119:
 The main roles of this extension are: The main roles of this extension are:
  
-  * Communication with ovs-vswitchd for configuration management and monitoring, as detailed in the Netlink paragraph above.+  * Communication with //ovs-vswitchd// for configuration management and monitoring, as detailed in the Netlink paragraph above.
   * Matching Hyper-V ports to OVS ports to identify the proper sources and destinations.    * Matching Hyper-V ports to OVS ports to identify the proper sources and destinations. 
   * Applying OpenFlow rules on the ingress / egress datapaths. This includes:   * Applying OpenFlow rules on the ingress / egress datapaths. This includes:
-  *Filtering +    * Filtering 
-  * Packet manipulation +    * Packet manipulation 
-  * GRE and VXLAN tunneling +    * GRE and VXLAN tunneling 
-  * Easy extendible to other encapsulation options (e.g. Geneve) +    * Easy extendible to other encapsulation options (e.g. Geneve) 
-  * VLAN tagging (optionally, as 802.1q is already supported by Hyper-V networking)+    * VLAN tagging (optionally, as 802.1q is already supported by Hyper-V networking)
  
-The extension contains all the low level packet manipulation with is required for the supported protocols (TCP, UDP, ICMP, etc) on both IPv4 and IPv6, including GRE and VXLAN packet encapsulation / decapsulation for tunneling. Please note that OVS uses currently GRE Ethertype 6558 only. +The extension contains all the low level packet manipulation wich is required for the supported protocols (TCP, UDP, ICMP, etc) on both IPv4 and IPv6, including GRE and VXLAN packet encapsulation / decapsulation for tunneling. In the GRE case, OVS uses currently Ethertype 6558 only. 
  
 Note: host tunnel endpoints are currently managed by setting //AllowManagementOS// to true on the Hyper-V virtual switch, thus delegating the adapter management to the OS. This requirement will be removed by managing host endpoints directly in the driver.   Note: host tunnel endpoints are currently managed by setting //AllowManagementOS// to true on the Hyper-V virtual switch, thus delegating the adapter management to the OS. This requirement will be removed by managing host endpoints directly in the driver.  
Line 143: Line 143:
 If the extension is enabled the driver starts processing the packets by extracting the source and destination details, including: tunnel id, tunnel flags, IPv4 source and destination address, IPv4 protocol, IPv4 fragment, IPv4 time to leave, packet priority and mark, OVS input port, Ethernet source and destination, VLAN tag and type, IPv6 source and destination address, IPv6 flow label, IPv6 source and destination port, IPv6 neighbour discovery. If the extension is enabled the driver starts processing the packets by extracting the source and destination details, including: tunnel id, tunnel flags, IPv4 source and destination address, IPv4 protocol, IPv4 fragment, IPv4 time to leave, packet priority and mark, OVS input port, Ethernet source and destination, VLAN tag and type, IPv6 source and destination address, IPv6 flow label, IPv6 source and destination port, IPv6 neighbour discovery.
  
-The packet is then matched against the Open Flow table cached in the driver and the relevant rules are applied, including decapsulation for GRE and VXLAN packets. If MAC-learning is enabled and the packet cannot be matched against existing rules, it is sent to userspace for further processing. The userspace ovs-vswitchd service processes the packet and determine the corresponding action for it, including the optional creation of a flow rule in the flowtable for this particular packet.+The packet is then matched against the Open Flow table cached in the driver and the relevant rules are applied, including decapsulation for GRE and VXLAN packets. If MAC-learning is enabled and the packet cannot be matched against existing rules, it is sent to userspace for further processing. The userspace //ovs-vswitchd// service processes the packet and determines the corresponding action for it, including the optional creation of a flow rule in the flowtable for this particular packet.
  
 Packets are finally sent to their destination Hyper-V ports using the //NdisFSendNetBufferLists// handler. Packets are finally sent to their destination Hyper-V ports using the //NdisFSendNetBufferLists// handler.
Line 204: Line 204:
 <code powershell> <code powershell>
 Connect-VMNetworkAdapter VM1 –SwitchName external Connect-VMNetworkAdapter VM1 –SwitchName external
-Get-VMNeworkAdapter VM1 | Set-VMNetworkAdapterOVSPort –OVSPortName vxlan-1+Get-VMNeworkAdapter VM1 | Set-VMNetworkAdapterOVSPort –OVSPortName "vxlan-1"
 </code> </code>
  
Line 211: Line 211:
 ===== Development and build system ===== ===== Development and build system =====
  
-The kernel driver can be compiled with Microsoft Visual Studio 2013, including the freely available [[http://www.visualstudio.com/downloads/download-visual-studio-vs#d-express-windows-desktop|"Express for Windows Destkop"]] version.  +The kernel driver can be compiled with Microsoft Visual Studio 2013, including the freely available [[http://www.visualstudio.com/downloads/download-visual-studio-vs#d-express-windows-desktop|"Express for Windows Destkop"]] edition.  
  
 Beside using the Visual Studio IDE, the driver can be built in fully automated mode on the command line as well: Beside using the Visual Studio IDE, the driver can be built in fully automated mode on the command line as well:
Line 223: Line 223:
 The driver must be signed with a valid Authenticode certificate in order to be deployed on non testing environments. The driver must be signed with a valid Authenticode certificate in order to be deployed on non testing environments.
  
-The Microsoft WHQL certification process can be started as soon as the code upstream merging is complete and a stable release milestone is reached.+The Microsoft WHQL certification process can be started as soon as the upstream code merging is complete and a stable release milestone is reached.
  
 ===== Continuos integration tests ===== ===== Continuos integration tests =====
  
-Continuous integration (CI) testing becomes mandatory from a practical standpoint, especially in case in which this effort is merged in the upstream OVS repository.+Continuous integration (CI) testing becomes mandatory from a practical standpoint, especially in the case in which this effort is merged in the upstream OVS repository.
  
 CI testing benefits: CI testing benefits:
Line 243: Line 243:
 ===== OpenStack use case ===== ===== OpenStack use case =====
  
-The main use case for this effort is to improve interoperability between Hyper-V and other virtualization solutions, OpenStack in particular, especially in the context of large multi-tenant cloud infrastructures.+The main use case for this effort is to improve interoperability between Hyper-V and other clouds / virtualization solutions, OpenStack in particular, especially in the context of large multi-tenant cloud infrastructures.
  
 The existing official Neutron Hyper-V agent, developed and maintained by Cloudbase Solutions as part of our ongoing OpenStack Hyper-V integration effort, offers full interoperability with flat or 802.1Q (VLAN) based networks in heterogeneous clouds (e.g. KVM, VMWare vSphere, XenServer etc), but it lacks a common ground when it comes to multi-tenant isolation based on tunneling. The existing official Neutron Hyper-V agent, developed and maintained by Cloudbase Solutions as part of our ongoing OpenStack Hyper-V integration effort, offers full interoperability with flat or 802.1Q (VLAN) based networks in heterogeneous clouds (e.g. KVM, VMWare vSphere, XenServer etc), but it lacks a common ground when it comes to multi-tenant isolation based on tunneling.
Line 253: Line 253:
 The Neutron OVS agent uses the OVS command line tools to apply the required L2 configurations for each instance on a given hypervisor host. By porting the user space tools we guarantee full compatibility across Linux and Windows for applying the switch configuration on a given host. The Neutron OVS agent uses the OVS command line tools to apply the required L2 configurations for each instance on a given hypervisor host. By porting the user space tools we guarantee full compatibility across Linux and Windows for applying the switch configuration on a given host.
  
-At the same time, the tunnelling features of the OVS Hyper-V extension take care of generating networking traffic fully compatible with Linux the counterparts.  Multi-tenancy is also guaranteed by the network isolation obtained by using separate tunnels and appropriate OpenFlow rules.+At the same time, the tunnelling features of the OVS Hyper-V extension take care of generating networking traffic fully compatible with the Linux counterparts.  Multi-tenancy is also guaranteed by the network isolation obtained by using separate tunnels and appropriate OpenFlow rules.
  
 A typical use case includes mixed Hyper-V and KVM hosts in an OpenStack deployment, as summarized by the following diagram: A typical use case includes mixed Hyper-V and KVM hosts in an OpenStack deployment, as summarized by the following diagram:
Line 262: Line 262:
  
   * Additional performance improvements   * Additional performance improvements
-  * Manage tunnel endpoints addresses in the driver to remove requirement for AllowManagementOS +  * Manage tunnel endpoints adapters in the driver to remove requirement for AllowManagementOS 
-  * Geneve encasulation+  * //Geneve// encasulation
   * Hardware offload for VXLAN encapsulation   * Hardware offload for VXLAN encapsulation
-  * Matching the ongoing development of new userspace features+  * Matching the ongoing development of new upstream userspace features
  
  
Line 276: Line 276:
 ===== Resources ===== ===== Resources =====
  
 +  * Installing and configuring the Hyper-V OVS extension: http://www.cloudbase.it/open-vswitch-on-hyper-v/
   * Hyper-V virtual switch architecture (TechNet): http://technet.microsoft.com/en-us/library/hh831823.aspx   * Hyper-V virtual switch architecture (TechNet): http://technet.microsoft.com/en-us/library/hh831823.aspx
   * Hyper-V virtual switch architecture (MSFT Blog): http://blogs.msdn.com/b/sdncorner/archive/2014/02/21/hyper-v-virtual-switch-architecture.aspx   * Hyper-V virtual switch architecture (MSFT Blog): http://blogs.msdn.com/b/sdncorner/archive/2014/02/21/hyper-v-virtual-switch-architecture.aspx
-  * Hyper-V virtual switch extension APIs: http://msdn.microsoft.com/en-us/library/windows/hardware/jj673961(v=vs.85).aspx+  * Hyper-V virtual switch extension APIs: [[http://msdn.microsoft.com/en-us/library/windows/hardware/jj673961(v=vs.85).aspx]]
   * OVS tutorial: http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=tutorial/Tutorial;hb=HEAD   * OVS tutorial: http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=tutorial/Tutorial;hb=HEAD
-  * Installing and configuring the Hyper-V OVS extension: http://www.cloudbase.it/open-vswitch-on-hyper-v/ 
   * Visual Studio 2013 Express (free): http://www.visualstudio.com/downloads/download-visual-studio-vs#d-express-windows-desktop   * Visual Studio 2013 Express (free): http://www.visualstudio.com/downloads/download-visual-studio-vs#d-express-windows-desktop
ovs-hyperv-architecture.1403482824.txt.gz · Last modified: 2014/06/23 03:20 by admin