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:29] admin [Kernel NDIS Hyper-V extension] |
ovs-hyperv-architecture [2014/06/23 03:39] (current) |
||
|---|---|---|---|
| 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.1403483364.txt.gz · Last modified: 2014/06/23 03:29 by admin
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
