User Tools
ovs-hyperv-architecture
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
ovs-hyperv-architecture [2014/06/23 03:21] admin [C99] |
ovs-hyperv-architecture [2014/06/23 03:39] (current) |
||
|---|---|---|---|
| Line 87: | Line 87: | ||
| * Various minor //# | * Various minor //# | ||
| - | 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 | + | * 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 |
| * 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 | + | 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 |
| Kernel: | Kernel: | ||
| Line 105: | Line 105: | ||
| {{: | {{: | ||
| - | User space (ovs-vswitchd and ovs-dpctl): | + | User space (//ovs-vswitchd// and //ovs-dpctl//): |
| {{: | {{: | ||
| 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: | ||
| - | | + | |
| - | * 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, | + | * VLAN tagging (optionally, |
| - | The extension contains all the low level packet manipulation | + | The extension contains all the low level packet manipulation |
| Note: host tunnel endpoints are currently managed by setting // | Note: host tunnel endpoints are currently managed by setting // | ||
| 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, | 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, | ||
| - | 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 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 |
| Packets are finally sent to their destination Hyper-V ports using the // | Packets are finally sent to their destination Hyper-V ports using the // | ||
| 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 |
| </ | </ | ||
| 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:// | + | The kernel driver can be compiled with Microsoft Visual Studio 2013, including the freely available [[http:// |
| 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 |
| ===== Continuos integration tests ===== | ===== Continuos integration tests ===== | ||
| - | Continuous integration (CI) testing becomes mandatory from a practical standpoint, especially in a 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. | + | 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. |
| 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 | + | * Manage tunnel endpoints |
| - | * 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 |
| Line 276: | Line 276: | ||
| ===== Resources ===== | ===== Resources ===== | ||
| + | * Installing and configuring the Hyper-V OVS extension: http:// | ||
| * Hyper-V virtual switch architecture (TechNet): http:// | * Hyper-V virtual switch architecture (TechNet): http:// | ||
| * Hyper-V virtual switch architecture (MSFT Blog): http:// | * Hyper-V virtual switch architecture (MSFT Blog): http:// | ||
| - | * Hyper-V virtual switch extension APIs: http:// | + | * Hyper-V virtual switch extension APIs: [[http:// |
| * OVS tutorial: http:// | * OVS tutorial: http:// | ||
| - | * Installing and configuring the Hyper-V OVS extension: http:// | ||
| * Visual Studio 2013 Express (free): http:// | * Visual Studio 2013 Express (free): http:// | ||
ovs-hyperv-architecture.1403482867.txt.gz · Last modified: 2014/06/23 03:21 (external edit)
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
