Manually configure an Open vSwitch GRE tunnel between VMs running on Hyper-V and KVM hosts in part three of this four-part series.

In this post we’ll explain how to manually configure an Open vSwitch GRE tunnel between VMs running on Hyper-V and KVM hosts.

KVM OVS configuration

In this example, KVM1 provides a GRE tunnel with local endpoint 14.14.14.1:

  • gre-1 connected to Hyper-V (14.14.14.2) through br-eth3

ubuntu@ubuntu:~$ sudo ovs-vsctl show
82585eef-349c-4573-8d77-91f9602bb535
    Bridge br-int
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
        Port "vm1"
            Interface "vm1"
                type: internal
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
    Bridge "br-eth3"
        Port "eth3"
            Interface "eth3"
        Port "br-eth3"
            Interface "br-eth3"
                type: internal
    Bridge br-tun
        fail_mode: secure
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, local_ip="14.14.14.2", out_key=flow, remote_ip="14.14.14.1"}
        Port br-tun
            Interface br-tun
                type: internal
ububtu@ubuntu:~$ ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 00:0c:29:25:db:8c  
          inet6 addr: fe80::20c:29ff:fe25:db8c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:40051 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51087 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6907123 (6.9 MB)  TX bytes:81805610 (81.8 MB)
ubuntu@ubuntu:~$ ifconfig br-eth3
br-eth3   Link encap:Ethernet  HWaddr 00:0c:29:25:db:8c  
          inet addr:14.14.14.1  Bcast:14.14.14.255  Mask:255.255.255.0
          inet6 addr: fe80::d413:1fff:fe62:cdd8/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:1377 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1573 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:315330 (315.3 KB)  TX bytes:283030 (283.0 KB)
ubuntu@@ubuntu:~$ ifconfig vm1
vm1       Link encap:Ethernet  HWaddr 6a:d6:1b:77:2d:95  
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::68d6:1bff:fe77:2d95/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1472  Metric:1
          RX packets:506 errors:0 dropped:0 overruns:0 frame:0
          TX packets:768 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:39788 (39.7 KB)  TX bytes:61932 (61.9 KB) 

Please note the MTU value on vm1 is set to 1472.

Hyper-V OVS configuration

Let’s assume you have a Hyper-V Virtual Switch of type external bound to the interface port1 called vSwitch.

The following commands will: create an IP-able device called br-port1, add the physical NIC to the bridge called br-port1, enable the device named br-port1, set the IP 14.14.14.2 to br-port1, add a bridge br-int in which we shall add the VMs later on and will create another bridge with the tunneling information on the port gre-1.

ovs-vsctl.exe add-br br-port1
ovs-vsctl.exe add-port br-port1 port1
Enable-NetAdapter br-port1
New-NetIpAddress -IpAddress 14.14.14.2 -PrefixLength 24 -InterfaceAlias br-port1
ovs-vsctl.exe add-br br-int
ovs-vsctl.exe add-port br-int patch-tun -- set interface patch-tun type=patch options:peer=patch-int
ovs-vsctl.exe add-br br-tun
ovs-vsctl.exe add-port br-tun patch-int -- set interface patch-int type=patch options:peer=patch-tun
ovs-vsctl.exe add-port br-tun gre-1 -- set interface gre-1 type=gre options:local_ip=14.14.14.2 options:remote_ip=14.14.14.1 options:in_key=flow options:out_key=flow

As you can see, all the commands are very familiar if you are used to OVS on Linux.

As introduced before, the main area where the Hyper-V implementation differs from its Linux counterpart is in how virtual machines are attached to a given OVS port. This is easily accomplished by using the Set-VMNetworkAdapterOVSPort PowerShell cmdlet provided with the installer (please refer to part 1 for details on installing OVS).

Let’s say we have a Hyper-V virtual machine called “instance-00000003” and that we want to connect it to the Hyper-V OVS switch. All we have to do for each VM network adapter is connect it to the Hyper-V Virtual Switch named vSwitch as you would normally do, assign it to a given OVS port and create the corresponding ports in OVS:

$vnic = Get-VMNetworkAdapter instance-00000003
Connect-VMNetworkAdapter -VMNetworkAdapter $vnic -SwitchName vSwitch
$vnic | Set-VMNetworkAdapterOVSPort -OVSPortName vm2
ovs-vsctl.exe add-port br-int vm2

Here’s how the resulting OVS configuration looks like on Hyper-V:

a81a54fc-0a3c-4152-9a0d-f3cbf4abc3ca
    Bridge br-int
        Port "vm2"
            Interface "vm2"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, local_ip="14.14.14.2", out_key=flow, remote_ip="14.14.14.1"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
    Bridge "br-port1"
        Port "port1"
            Interface "port1"
        Port "br-port1"
            Interface "br-port1"
                type: internal 

Further control can be accomplished by applying flow rules.

OVS-based networking is now fully functional between KVM and Hyper-V hosted virtual machines!

P.S.: Don’t forget to check out part one (OpenStack) and part two (VXLAN) of this series if you missed them!

This post first appeared on the Cloudbase Solutions blog. Superuser is always interested in community content, email: editor@superuser.org.

Cover Photo // CC BY NC