| 2023-12-03 07:36:45 |
Frode Nordahl |
bug |
|
|
added bug |
| 2023-12-03 07:39:43 |
Frode Nordahl |
description |
The MicroOVN snap provides among other things Open vSwitch.
In some configurations, it can be useful to use an Open vSwitch bridge to provide network connectivity to the host itself, for example for single NIC configurations.
There are two reasons to prefer OVS bridges over Linux bridges in this setup:
1) When using linux bridges for host networking traffic to instances will need to traverse multiple levels of slow path indirections, affecting performance. When using an OVS bridge for host networking you only need one bridge.
2) Using an OVS bridge makes it possible to offload network traffic to fast path for systems with hardware offload capable NICs.
With the Netplan Open vSwitch integration and in-flight patches [0] to consume Open vSwitch from snap this can be done with MicroOVN today with some manual tweaking. Let's get rid of that manual tweaking!
To make it work I had to manually create the runtime directories for Open vSwitch, i.e:
cd /var/snap/microovn/common/
sudo mkdir -p run/switch logs data/switch/db
sudo snap service --enable start microovn.switch
After doing that I could continue with netplan configuration and ultimately initialize a MicroCloud that uses a single NIC both for host and instance networking.
The root of the issue appears to be that MicroOVN currently defers the creation of the requried directories to the `microovnd` daemon on cluster bootstrap. Given we need to start the switch service prior to bootstrap this appears like a artificial and limiting dependency.
0: https://github.com/canonical/netplan/pull/425 |
The MicroOVN snap provides among other things Open vSwitch.
In some configurations, it can be useful to use an Open vSwitch bridge to provide network connectivity to the host itself, for example for single NIC configurations.
There are two reasons to prefer OVS bridges over Linux bridges in this setup:
1) When using linux bridges for host networking traffic to instances will need to traverse multiple levels of slow path indirections, affecting performance. When using an OVS bridge for host networking you only need one bridge.
2) Using an OVS bridge makes it possible to offload network traffic to fast path for systems with hardware offload capable NICs.
With the Netplan Open vSwitch integration and in-flight patches [0] to consume Open vSwitch from snap this can be done with MicroOVN today with some manual tweaking. Let's get rid of that manual tweaking!
To make it work I had to manually create the runtime directories for Open vSwitch, i.e:
cd /var/snap/microovn/common/
sudo mkdir -p run/switch logs data/switch/db
sudo snap service --enable start microovn.switch
After doing that I could continue with netplan configuration, example:
network:
version: 2
ethernets:
eth0:
match:
macaddress: 00:16:3e:2e:cd:5d
set-name: eth0
bridges:
br-eth0:
interfaces: [eth0]
macaddress: 00:16:3e:2e:cd:5d
dhcp4: true
openvswitch: {}
...and ultimately initialize a MicroCloud that uses a single NIC both for host and instance networking.
The root of the issue appears to be that MicroOVN currently defers the creation of the requried directories to the `microovnd` daemon on cluster bootstrap. Given we need to start the switch service prior to bootstrap this appears like a artificial and limiting dependency.
0: https://github.com/canonical/netplan/pull/425 |
|
| 2023-12-03 07:41:48 |
Frode Nordahl |
description |
The MicroOVN snap provides among other things Open vSwitch.
In some configurations, it can be useful to use an Open vSwitch bridge to provide network connectivity to the host itself, for example for single NIC configurations.
There are two reasons to prefer OVS bridges over Linux bridges in this setup:
1) When using linux bridges for host networking traffic to instances will need to traverse multiple levels of slow path indirections, affecting performance. When using an OVS bridge for host networking you only need one bridge.
2) Using an OVS bridge makes it possible to offload network traffic to fast path for systems with hardware offload capable NICs.
With the Netplan Open vSwitch integration and in-flight patches [0] to consume Open vSwitch from snap this can be done with MicroOVN today with some manual tweaking. Let's get rid of that manual tweaking!
To make it work I had to manually create the runtime directories for Open vSwitch, i.e:
cd /var/snap/microovn/common/
sudo mkdir -p run/switch logs data/switch/db
sudo snap service --enable start microovn.switch
After doing that I could continue with netplan configuration, example:
network:
version: 2
ethernets:
eth0:
match:
macaddress: 00:16:3e:2e:cd:5d
set-name: eth0
bridges:
br-eth0:
interfaces: [eth0]
macaddress: 00:16:3e:2e:cd:5d
dhcp4: true
openvswitch: {}
...and ultimately initialize a MicroCloud that uses a single NIC both for host and instance networking.
The root of the issue appears to be that MicroOVN currently defers the creation of the requried directories to the `microovnd` daemon on cluster bootstrap. Given we need to start the switch service prior to bootstrap this appears like a artificial and limiting dependency.
0: https://github.com/canonical/netplan/pull/425 |
The MicroOVN snap provides among other things Open vSwitch.
In some configurations, it can be useful to use an Open vSwitch bridge to provide network connectivity to the host itself, for example for single NIC configurations.
There are two reasons to prefer OVS bridges over Linux bridges in this setup:
1) When using linux bridges for host networking traffic to instances will need to traverse multiple levels of slow path indirections, affecting performance. When using an OVS bridge for host networking you only need one bridge.
2) Using an OVS bridge makes it possible to offload network traffic to fast path for systems with hardware offload capable NICs.
With the Netplan Open vSwitch integration and in-flight patches [0] to consume Open vSwitch from snap this can be done with MicroOVN today with some manual tweaking. Let's get rid of that manual tweaking!
To make it work I had to manually create the runtime directories for Open vSwitch, i.e:
cd /var/snap/microovn/common/
sudo mkdir -p run/switch logs data/switch/db
sudo snap service --enable start microovn.switch
sudo snap alias microovn.ovs-vsctl ovs-vsctl
After doing that I could continue with netplan configuration, example:
network:
version: 2
ethernets:
eth0:
match:
macaddress: 00:16:3e:2e:cd:5d
set-name: eth0
bridges:
br-eth0:
interfaces: [eth0]
macaddress: 00:16:3e:2e:cd:5d
dhcp4: true
openvswitch: {}
...and ultimately initialize a MicroCloud that uses a single NIC both for host and instance networking.
The root of the issue appears to be that MicroOVN currently defers the creation of the requried directories to the `microovnd` daemon on cluster bootstrap. Given we need to start the switch service prior to bootstrap this appears like a artificial and limiting dependency.
0: https://github.com/canonical/netplan/pull/425 |
|
| 2023-12-04 06:35:57 |
Frode Nordahl |
description |
The MicroOVN snap provides among other things Open vSwitch.
In some configurations, it can be useful to use an Open vSwitch bridge to provide network connectivity to the host itself, for example for single NIC configurations.
There are two reasons to prefer OVS bridges over Linux bridges in this setup:
1) When using linux bridges for host networking traffic to instances will need to traverse multiple levels of slow path indirections, affecting performance. When using an OVS bridge for host networking you only need one bridge.
2) Using an OVS bridge makes it possible to offload network traffic to fast path for systems with hardware offload capable NICs.
With the Netplan Open vSwitch integration and in-flight patches [0] to consume Open vSwitch from snap this can be done with MicroOVN today with some manual tweaking. Let's get rid of that manual tweaking!
To make it work I had to manually create the runtime directories for Open vSwitch, i.e:
cd /var/snap/microovn/common/
sudo mkdir -p run/switch logs data/switch/db
sudo snap service --enable start microovn.switch
sudo snap alias microovn.ovs-vsctl ovs-vsctl
After doing that I could continue with netplan configuration, example:
network:
version: 2
ethernets:
eth0:
match:
macaddress: 00:16:3e:2e:cd:5d
set-name: eth0
bridges:
br-eth0:
interfaces: [eth0]
macaddress: 00:16:3e:2e:cd:5d
dhcp4: true
openvswitch: {}
...and ultimately initialize a MicroCloud that uses a single NIC both for host and instance networking.
The root of the issue appears to be that MicroOVN currently defers the creation of the requried directories to the `microovnd` daemon on cluster bootstrap. Given we need to start the switch service prior to bootstrap this appears like a artificial and limiting dependency.
0: https://github.com/canonical/netplan/pull/425 |
The MicroOVN snap provides among other things Open vSwitch.
In some configurations, it can be useful to use an Open vSwitch bridge to provide network connectivity to the host itself, for example for single NIC configurations.
There are two reasons to prefer OVS bridges over Linux bridges in this setup:
1) When using linux bridges for host networking traffic to instances will need to traverse multiple levels of slow path indirections, affecting performance. When using an OVS bridge for host networking you only need one bridge.
2) Using an OVS bridge makes it possible to offload network traffic to fast path for systems with hardware offload capable NICs.
With the Netplan Open vSwitch integration and in-flight patches [0] to consume Open vSwitch from snap this can be done with MicroOVN today with some manual tweaking. Let's get rid of that manual tweaking!
To make it work I had to manually create the runtime directories for Open vSwitch, i.e:
cd /var/snap/microovn/common/
sudo mkdir -p run/switch logs data/switch/db
sudo snap start --enable microovn.switch
sudo snap alias microovn.ovs-vsctl ovs-vsctl
After doing that I could continue with netplan configuration, example:
network:
version: 2
ethernets:
eth0:
match:
macaddress: 00:16:3e:2e:cd:5d
set-name: eth0
bridges:
br-eth0:
interfaces: [eth0]
macaddress: 00:16:3e:2e:cd:5d
dhcp4: true
openvswitch: {}
...and ultimately initialize a MicroCloud that uses a single NIC both for host and instance networking.
The root of the issue appears to be that MicroOVN currently defers the creation of the requried directories to the `microovnd` daemon on cluster bootstrap. Given we need to start the switch service prior to bootstrap this appears like a artificial and limiting dependency.
0: https://github.com/canonical/netplan/pull/425 |
|
