Skip to content

Add warning about OVS plugin #241

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
yadvr merged 2 commits into from
Sep 22, 2021
Merged

Add warning about OVS plugin #241

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4543cb1
Add warning about OVS plugin
davidjumani Sep 13, 2021
fbf85d0
Update ovs-plugin.rst
davidjumani Sep 22, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 37 additions & 34 deletions source/plugins/ovs-plugin.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,12 +17,21 @@
The OVS Plugin
==============

.. warning::
The OVS Plugin was not maintained in some CloudStack versions. Please use CloudStack
4.16.0.0 and later. If you wish to use OVS as the default networking backend on Linux,
only follow the Agent Configuration part of this guide.
CloudStack will automatically detect it up based on the configuration in the
agent.properties file. This in spite of the OVS Plugin not being shown in the
Network Service Providers.


Introduction to the OVS Plugin
------------------------------

The OVS plugin is the native SDN
implementations in CloudStack, using GRE isolation method. The plugin can be
used by CloudStack to implement isolated guest networks and to provide
implementations in CloudStack, using GRE isolation method. The plugin can be
used by CloudStack to implement isolated guest networks and to provide
additional services like NAT, port forwarding and load balancing.


Expand All @@ -48,12 +57,6 @@ the OVS Plugin.

Table: Supported Services

.. note::
If you wish to use OVS as the default networking backend on Linux,
just follow this guide and CloudStack will automatically pick it up
based on the configuration in the agent.properties file. This in spite
of the OVS Plugin not being shown in the Network Service Providers.

.. note::
The Virtual Networking service was originally called 'Connectivity'
in CloudStack 4.0
Expand All @@ -79,19 +82,19 @@ Configuring the OVS Plugin
Prerequisites
~~~~~~~~~~~~~

Before enabling the OVS plugin the hypervisor needs to be install OpenvSwitch.
Default, XenServer has already installed OpenvSwitch. However, you must
install OpenvSwitch manually on KVM. CentOS 6.4 and OpenvSwitch 1.10 are
Before enabling the OVS plugin the hypervisor needs to be install OpenvSwitch.
Default, XenServer has already installed OpenvSwitch. However, you must
install OpenvSwitch manually on KVM. CentOS 6.4 and OpenvSwitch 1.10 are
recommended.

KVM hypervisor:

- CentOS 6.4 is recommended.

- To make sure that the native bridge module will not interfere with
openvSwitch the bridge module should be added to the blacklist. See the
modprobe documentation for your distribution on where to find the blacklist.
Make sure the module is not loaded either by rebooting or executing rmmod
- To make sure that the native bridge module will not interfere with
openvSwitch the bridge module should be added to the blacklist. See the
modprobe documentation for your distribution on where to find the blacklist.
Make sure the module is not loaded either by rebooting or executing rmmod
bridge before executing next steps.


Expand All @@ -104,7 +107,7 @@ traffic type.

.. note::
With KVM, the traffic type should be configured with the traffic label
that matches the name of the Integration Bridge on the hypervisor. For
that matches the name of the Integration Bridge on the hypervisor. For
example, you should set the traffic label as following:

- Management & Storage traffic: cloudbr0
Expand All @@ -127,7 +130,7 @@ Agent Configuration
- Configure network interfaces:

::

/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
Expand All @@ -137,7 +140,7 @@ Agent Configuration
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=cloudbr0

/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
Expand All @@ -147,7 +150,7 @@ Agent Configuration
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=cloudbr1

/etc/sysconfig/network-scripts/ifcfg-cloudbr0
DEVICE=cloudbr0
ONBOOT=yes
Expand All @@ -158,15 +161,15 @@ Agent Configuration
GATEWAY=172.16.10.1
NETMASK=255.255.255.0
HOTPLUG=no

/etc/sysconfig/network-scripts/ifcfg-cloudbr1
DEVICE=cloudbr1
ONBOOT=yes
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=none
HOTPLUG=no

/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=testkvm1
Expand All @@ -175,7 +178,7 @@ Agent Configuration
- Edit /etc/cloudstack/agent/agent.properties

::

network.bridge.type=openvswitch
libvirt.vif.driver=com.cloud.hypervisor.kvm.resource.OvsVifDriver

Expand Down Expand Up @@ -286,7 +289,7 @@ Agent configuration
- Edit /etc/cloudstack/agent/agent.properties to enable DPDK support on the agent and on ovs-vstcl commands for port creations as well as the path to OVS ports (usually: /var/run/openvswitch)

::

openvswitch.dpdk.enabled=true
openvswitch.dpdk.ovs.path=OVS_PATH

Expand All @@ -295,15 +298,15 @@ Agent should be restarted for actions to take effect.
When the host agent connects to the management server, it sends the list of hosts capabilities. When DPDK support is enabled on the host, the capability with name 'dpdk' is sent to the management server. The list of host capabilities are persisted on the 'capabilities' column on 'hosts' table, and can be retrieved by the 'listHosts' API method:

::

list hosts id=HOST_ID filter=capabilities

Additional VM configurations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to enable DPDK on VM deployments, users should pass addition configuration to VMs. The required configurations are listed on the next section. Administrators can allow users to pass additional configurations to their VMs by the account scoped setting:

::

enable.additional.vm.configuration

Users are able to pass extra configurations as part of the 'deployVirtualMachine' or 'updateVirtualMachine' API methods.
Expand All @@ -323,7 +326,7 @@ Example:
In order to pass the below extra configuration to the VM, named 'config-1'

::

config-1:
<tag>
<inner-tag>VALUE</inner-tag>
Expand All @@ -332,26 +335,26 @@ In order to pass the below extra configuration to the VM, named 'config-1'
The 'extraconfig' parameter should receive the UTF-8 URL encoded string:

::

config-1%3A%0A%3Ctag%3E%0A%20%20%20%3Cinner-tag%3EVALUE%3C%2Finner-tag%3E%0A%3C%2Ftag%3E

On 'user_vm_details' table the additional configuration is persisted with key: 'extraconfig-config-1'


Additional configurations to enable DPDK on VMs
Additional configurations to enable DPDK on VMs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To enable DPDK on VM deployments:

- Set the global configuration to 'true' (as global setting or account setting)

::

enable.additional.vm.configuration

- Generate the UTF-8 URL encoded additional configuration to enable huge pages and NUMA, examples below:

::

dpdk-hugepages:
<memoryBacking>
<hugepages>
Expand All @@ -368,13 +371,13 @@ To enable DPDK on VM deployments:
- Pass the 'extraconfig' parameter to 'deployVirtualMachine' or 'updateVirtualMachine' API methods as a single UTF-8 URL encoded string containing multiple extra configurations (as shown above). Note: if multiple extra configurations are needed, follow the example above and add new sections separated by an empty line, encode the whole string and pass it as a single string to the APIs as 'extraconfig' parameter.

::

deployVirtualMachine extraconfig=dpdk-hugepages%3A%0A%3CmemoryBacking%3E%0A%20%20%20%3Chugepages%3E%0A%20%20%20%20%3C%2Fhugepages%3E%0A%3C%2FmemoryBacking%3E%0A%0Adpdk-numa%3A%0A%3Ccpu%20mode%3D%22host-passthrough%22%3E%0A%20%20%20%3Cnuma%3E%0A%20%20%20%20%20%20%20%3Ccell%20id%3D%220%22%20cpus%3D%220%22%20memory%3D%229437184%22%20unit%3D%22KiB%22%20memAccess%3D%22shared%22%2F%3E%0A%20%20%20%3C%2Fnuma%3E%0A%3C%2Fcpu%3E%0A

- Additionally, users can pass extra configuration named 'dpdk-interface-TAG' to be included on VMs interfaces definition. Example below:

::

dpdk-interface-model:
<model type='virtio'/>

Expand Down Expand Up @@ -403,7 +406,7 @@ It is possible to avoid passing additional configuration on each VM deployment,
For example, applying DPDK additional configurations via service offering:

::

create serviceoffering name=<NAME> displaytext=<NAME> serviceofferingdetails[0].key=extraconfig-dpdk-hugepages serviceofferingdetails[0].value=%3CmemoryBacking%3E%20%3Chugepages%2F%3E%20%3C%2FmemoryBacking%3E serviceofferingdetails[1].key=extraconfig-dpdk-numa serviceofferingdetails[1].value=%3Ccpu%20mode%3D%22host-passthrough%22%3E%20%3Cnuma%3E%20%3Ccell%20id%3D%220%22%20cpus%3D%220%22%20memory%3D%229437184%22%20unit%3D%22KiB%22%20memAccess%3D%22shared%22%2F%3E%20%3C%2Fnuma%3E%20%3C%2Fcpu%3E

The preferred DPDK vHost User Mode must be passed as a service offering detail, with special key name: "DPDK-VHOSTUSER". Possible values are: "client" or "server". The following table illustrates the expected behaviour on DPDK ports and VM guest interfaces.
Expand All @@ -419,7 +422,7 @@ By default, the server mode is assumed if it is not passed as a service offering
+----------------------+------------------------+-------------------------+

::

create serviceoffering name=<NAME> displaytext=<NAME> serviceofferingdetails[0].key=DPDK-VHOSTUSER serviceofferingdetails[0].value=client serviceofferingdetails[1].key=extraconfig-dpdk-hugepages serviceofferingdetails[1].value=%3CmemoryBacking%3E%20%3Chugepages%2F%3E%20%3C%2FmemoryBacking%3E serviceofferingdetails[2].key=extraconfig-dpdk-numa serviceofferingdetails[2].value=%3Ccpu%20mode%3D%22host-passthrough%22%3E%20%3Cnuma%3E%20%3Ccell%20id%3D%220%22%20cpus%3D%220%22%20memory%3D%229437184%22%20unit%3D%22KiB%22%20memAccess%3D%22shared%22%2F%3E%20%3C%2Fnuma%3E%20%3C%2Fcpu%3E

DPDK VMs live migrations
Expand Down