and configuring. This configuration guide outlines how to install and
configure components in order to enable the features required.
-.. include:: ./scenariomatrix.rst
+#.. include:: ./scenariomatrix.rst
D
~
+Danube
+
+ Danube is the fourth release of OPNFV and also a river in Europe
+
Data plane
The data plane is the part of a network that carries user traffic.
./configurationguide/abstract.rst
./configurationguide/configuration.options.render.rst
- ./configurationguide/low-latency.feature.configuration.description.rst
./configurationguide/scenariomatrix.rst
+ ./configurationguide/low-latency.feature.configuration.description.rst
********************************************
KVMFORNFV Scenarios Overview and Description
---------------
These build scripts are triggered on the Jenkins-Slave build server. Currently
-Intel POD1 is used as test environment for kvmfornfv to execute cyclictest. As
-part of this test environment Intel pod1-jump is configured as jenkins slave
-and all the latest build artifacts are downloaded on to it. Intel pod1-node1
+Intel POD10 is used as test environment for kvmfornfv to execute cyclictest. As
+part of this test environment Intel pod10-jump is configured as jenkins slave
+and all the latest build artifacts are downloaded on to it. Intel pod10-node1
is the host on which a guest vm will be launched as a part of running cylictest
through yardstick.
Builds are possible for the following packages-
-**kvmfornfv source code**- The ./ci/build.sh is the main script used to trigger
+**kvmfornfv source code**
+
+The ./ci/build.sh is the main script used to trigger
the Rpms (on 'centos') and Debians (on 'ubuntu') builds in this case.
* How to build Kernel/Qemu Rpms- To build rpm packages, build.sh script is run
| **JIRA REFERENCE** | **SLOGAN** |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-34 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-34 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-57 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-57 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-58 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-58 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-59 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-59 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-60 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-60 |
| | |
+--------------------------------------+--------------------------------------+
| **JIRA REFERENCE** | **SLOGAN** |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | |
+| JIRA: | NFV Hypervisors-KVMFORNFV-75 |
+--------------------------------------+--------------------------------------+
| JIRA: | |
+--------------------------------------+--------------------------------------+
Workarounds
-----------
-See JIRA: <link>
+See JIRA: https://jira.opnfv.org/projects
References
.. http://creativecommons.org/licenses/by/4.0
-=============================
-KMV4MFV CICD Project Overview
-=============================
+===============================
+KVMFORNFV CICD Project Overview
+===============================
The detailed understanding of this project is organized into different sections-
* **userguide** - This provides the required technical assistance to the user, in
using the KVM4NFV CICD process.
-* **installationprocedure** - This will give the user instructions on how to deploy
+* **installation procedure** - This will give the user instructions on how to deploy
available KVM4NFV CICD build scenario.
-* **configurationguide** - This provides guidance for configuring KVM4NFV
+* **configuration guide** - This provides guidance for configuring KVM4NFV
environment, even with the use of specific installer tools for deploying some
components, available in the Danube release of OPNFV.
* **requirements** - This includes the introduction of KVM4NFV CICD project,
account for achieving minimal interrupt latency for the data VNFs.
* **scenarios** - This includes the sceanrios that are currently implemented in the
kvmfornfv project,features of each scenario and a general guide to how to deploy them.
-* **releasenotes** - This describes a brief summary of recent changes, enhancements
+* **release notes** - This describes a brief summary of recent changes, enhancements
and bug fixes in the KVM4NFV project.
* **glossary** - It includes the definition of terms, used in the KVM4NFV project.
**Contents**
- 1 Version History
+ **1 Version History**
- 2 Important notes
+ **2 Important notes**
- 3 Summary
+ **3 Summary**
- 4 Delivery Data
+ **4 Delivery Data**
- 5 References
+ **5 References**
-1. Version history
---------------------
+Version history
+---------------
+--------------------+--------------------+--------------------+----------------------+
| **Date** | **Ver.** | **Author** | **Comment** |
| | | | |
+--------------------+--------------------+--------------------+----------------------+
-2. Important notes
---------------------
+Important notes
+---------------
The KVMFORNFV project is currently supported on the Fuel installer.
-3. Summary
-------------
+Summary
+-------
This Danube 1.0 release provides *KVMFORNFV* as a framework to enhance the
KVM Hypervisor for NFV and OPNFV scenario testing, automated in the OPNFV
* Cyclictests execution to check the latency
-* “os-sdn-kvm-ha”,“os-sdn-kvm-_nfv_ovs_dpdk-ha”,“os-sdn-kvm_nfv_ovs_dpdk-noha”,“os-sdn-kvm_nfv_ovs_dpdk_bar-ha”,“os-sdn-kvm_nfv_ovs_dpdk_bar-noha” Scenarios testing for high availability configuration using Fuel installer
+* “os-nosdn-kvm-ha”,“os-nosdn-kvm_nfv_ovs_dpdk-ha”,“os-nosdn-kvm_nfv_ovs_dpdk-noha”,“os-nosdn-kvm_nfv_ovs_dpdk_bar-ha”,
+ “os-nosdn-kvm_nfv_ovs_dpdk_bar-noha” Scenarios testing for ``high availability/no-high avaliability``
+ configuration using Fuel installer
-* Documentation created
+* Documentation created for,
* User Guide
* Release notes (this document)
+ * Scenarios
+
The *KVMFORNFV framework* is developed in the OPNFV community, by the
KVMFORNFV_ team.
-4. Release Data
------------------
+Release Data
+------------
+--------------------------------------+--------------------------------------+
| **Project** | NFV Hypervisors-KVM |
| | |
+--------------------------------------+--------------------------------------+
-4.1 Version change
-------------------
+Version change
+--------------
-4.1.1 Module version changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1 Module version changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~
This is the Danube 1.0 main release. It is based on following upstream
versions:
-* RT Kernel 4.4.6-rt14
+* RT Kernel 4.4.50-rt62
* QEMU 2.6
This is the second tracked release of KVMFORNFV
-4.1.2 Document version changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+2 Document version changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is the initial version of the KVMFORNFV framework in OPNFV.
-4.2 Reason for version
-----------------------
+Reason for version
+------------------
-4.2.1 Feature additions
-~~~~~~~~~~~~~~~~~~~~~~~
+1 Feature additions
+~~~~~~~~~~~~~~~~~~~
+--------------------------------------+--------------------------------------+
| **JIRA REFERENCE** | **SLOGAN** |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-57 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-57 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-58 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-58 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-59 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-59 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-61 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-61 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-62 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-62 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-63 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-63 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-64 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-64 |
| | |
+--------------------------------------+--------------------------------------+
-| JIRA: | NFV Hypervisors-KVMKVMFORNFV-65 |
+| JIRA: | NFV Hypervisors-KVMFORNFV-65 |
| | |
+--------------------------------------+--------------------------------------+
-4.2.2 Bug corrections
-~~~~~~~~~~~~~~~~~~~~~
+2 Bug corrections
+~~~~~~~~~~~~~~~~~
Initial Release
-4.3 Deliverables
-----------------
+Deliverables
+------------
-4.3.1 Software deliverables
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1 Software deliverables
+~~~~~~~~~~~~~~~~~~~~~~~~~
Danube 1.0 release of the KVMFORNFV RPM and debian for Fuel.
-4.3.2 Documentation deliverables
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+2 Documentation deliverables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The below documents are delivered for Danube KVMFORNFV Release:
* Scenarios
-5. References
---------------
+References
+----------
For more information on the KVMFORNFV Danube release, please see:
.. (c) OPNFV, Intel Corporation, AT&T and others.
======================
-kvmfornfv Requirements
+Kvmfornfv Requirements
======================
Introduction
+------------------------------------------+------------------+-----------------+
| **Scenario Name** | **Colorado** | **Danube** |
| | | |
-+------------------------------------------+------------------+-----------------+
++==========================================+==================+=================+
| - os-nosdn-kvm-ha | ``Y`` | ``Y`` |
-| | | |
++------------------------------------------+------------------+-----------------+
| - os-nosdn-kvm_nfv_ovs_dpdk-noha | | ``Y`` |
-| | | |
++------------------------------------------+------------------+-----------------+
| - os-nosdn-kvm_nfv_ovs_dpdk-ha | | ``Y`` |
-| | | |
++------------------------------------------+------------------+-----------------+
| - os-nosdn-kvm_nfv_ovs_dpdk_bar-noha | | ``Y`` |
-| | | |
++------------------------------------------+------------------+-----------------+
| - os-nosdn-kvm_nfv_ovs_dpdk_bar-ha | | ``Y`` |
-| | | |
+------------------------------------------+------------------+-----------------+
D- Release Scenario's overview
-------------------------------
-+--------------------------------------+-----------------------+---------------------+--------------------+-------------+------------+
-| **Scenario Name** | **No of Controllers** | **No of Computes** | ** Plugins Name** | ** DPDK** | ** OVS ** |
-| | | | | | |
-+--------------------------------------+-----------------------+---------------------+--------------------+-------------+------------+
-| - os-nosdn-kvm_nfv_ovs_dpdk-noha | ``1`` | ``3`` | ``KVM`` | ``Y`` | ``Y`` |
-| | | | | | |
-| - os-nosdn-kvm_nfv_ovs_dpdk-ha | ``3`` | ``2`` | ``KVM`` | ``Y`` | ``Y`` |
-| | | | | | |
-| - os-nosdn-kvm_nfv_ovs_dpdk_bar-noha | ``1`` | ``2`` | ``KVM & BAR`` | ``Y`` | ``Y`` |
-| | | | | | |
-| - os-nosdn-kvm_nfv_ovs_dpdk_bar-ha | ``3`` | ``3`` | ``KVM & BAR`` | ``Y`` | ``Y`` |
-| | | | | | |
-+--------------------------------------+-----------------------+---------------------+--------------------+-------------+------------+
++------------------------------------------+-----------------------+---------------------+------------------+----------+----------+
+| **Scenario Name** | **No of Controllers** | **No of Computes** | **Plugin Names** | **DPDK** | **OVS** |
+| | | | | | |
++==========================================+=======================+=====================+==================+==========+==========+
+| - ``os-nosdn-kvm_nfv_ovs_dpdk-noha`` | 1 | 3 | KVM | Y | Y |
++------------------------------------------+-----------------------+---------------------+------------------+----------+----------+
+| - ``os-nosdn-kvm_nfv_ovs_dpdk-ha`` | 3 | 2 | KVM | Y | Y |
++------------------------------------------+-----------------------+---------------------+------------------+----------+----------+
+| - ``os-nosdn-kvm_nfv_ovs_dpdk_bar-noha`` | 1 | 3 | KVM & BAR | Y | Y |
++------------------------------------------+-----------------------+---------------------+------------------+----------+----------+
+| - ``os-nosdn-kvm_nfv_ovs_dpdk_bar-ha`` | 3 | 2 | KVM & BAR | Y | Y |
++------------------------------------------+-----------------------+---------------------+------------------+----------+----------+
.. http://creativecommons.org/licenses/by/4.0
-========================
-KVM4NFV SCENARIO-TESTING
-========================
+==============================
+KVMFORNFV Scenario-Description
+==============================
-ABSTRACT
+Abstract
--------
This document describes the procedure to deploy/test KVM4NFV scenarios in a nested virtualization
+-----------------------------+---------------------------------------------+
-INTRODUCTION
+Introduction
------------
The purpose of os-nosdn-kvm_ovs_dpdk-ha,os-nosdn-kvm_ovs_dpdk_bar-ha and
os-nosdn-kvm_ovs_dpdk-noha,os-nosdn-kvm_ovs_dpdk_bar-noha scenarios testing is to
KVMFORNFV packages will be installed on compute nodes as part of deployment.
The scenario testcase deploys a multi-node setup by using OPNFV Fuel deployer.
-1. System pre-requisites
-------------------------
+System pre-requisites
+---------------------
- RAM - Minimum 16GB
- HARD DISK - Minimum 500GB
EOF
$ sudo reboot
-2. Environment Setup
---------------------
+Environment Setup
+-----------------
-**2.1 Configuring Proxy**
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+**Configuring Proxy**
+~~~~~~~~~~~~~~~~~~~~~
For **Ubuntu**.,
Create an apt.conf file in /etc/apt if it doesn't exist. Used to set proxy for apt-get if working behind a proxy server.
$ echo "proxy=http://<username>:<password>@<proxy>:<port>/" >> /etc/yum.conf
-**2.2 Network Time Protocol (NTP) setup and configuration**
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+**Network Time Protocol (NTP) setup and configuration**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Install ntp by:
$ sudo service ntp restart
-3. Scenario Testing
--------------------
+Scenario Testing
+----------------
There are three ways of performing scenario testing,
- - 3.1 Fuel
- - 3.2 OPNFV-Playground
- - 3.3 Jenkins Project
+ - 1 Fuel
+ - 2 OPNFV-Playground
+ - 3 Jenkins Project
-3.1 Fuel
-~~~~~~~~
+Fuel
+~~~~
-**3.1.1 Clone the fuel repo :**
+**1 Clone the fuel repo :**
.. code:: bash
$ git clone https://gerrit.opnfv.org/gerrit/fuel.git
-**3.1.2 Checkout to the specific version of the branch to deploy by:**
+**2 Checkout to the specific version of the branch to deploy by:**
The default branch is master, to use a stable release-version use the below.,
To check out a specific branch
$ git checkout stable/Colorado
-**3.1.3 Building the Fuel iso :**
+**3 Building the Fuel iso :**
.. code:: bash
http://artifacts.opnfv.org/fuel.html
-**3.1.4 Creating a new deployment scenario**
+**4 Creating a new deployment scenario**
-``(i). Naming the scenario file:``
+``(i). Naming the scenario file``
Include the new deployment scenario yaml file in ~/fuel/deploy/scenario/. The file name should adhere to the following format:
<ha | no-ha>_<SDN Controller>_<feature-1>_..._<feature-n>.yaml
``(ii). Meta data``
+
The deployment configuration file should contain configuration metadata as stated below:
.. code:: bash
created:
``(iii). “stack-extentions” Module``
- To include fuel plugins in the deployment configuration file, use the “stack-extentions” key:
+
+To include fuel plugins in the deployment configuration file, use the “stack-extentions” key:
.. code:: bash
**Note:**
The “module-config-name” and “module-config-version” should be same as the name of plugin configuration file.
-The “module-config-override” is used to configure the plugin by overrriding the corresponding keys in the plugin config yaml file present in ~/fuel/deploy/config/plugins/.
+The “module-config-override” is used to configure the plugin by overrriding the corresponding keys in
+the plugin config yaml file present in ~/fuel/deploy/config/plugins/.
``(iv). “dea-override-config” Module``
+
To configure the HA/No-HA mode, network segmentation types and role to node assignments, use the “dea-override-config” key.
.. code:: bash
corresponding keys in the dea_base.yaml and dea_pod_override.yaml.
``(v). “dha-override-config” Module``
+
In order to configure the pod dha definition, use the “dha-override-config” key.
This is an optional key present at the ending of the scenario file.
``(vi). Mapping to short scenario name``
+
The scenario.yaml file is used to map the short names of scenario's to the one or more deployment scenario configuration yaml files.
The short scenario names should follow the scheme below:
- ( _ ) used to separate the values belong to the same field. [os-nosdn-kvm_ovs_bar-ha].
-**3.1.5 Deploying the scenario**
-
+**5 Deploying the scenario**
Command to deploy the os-nosdn-kvm_ovs_dpdk-ha scenario:
Check $ sudo ./deploy.sh -h for further information.
-3.2 OPNFV-Playground
-~~~~~~~~~~~~~~~~~~~~
+OPNFV-Playground
+~~~~~~~~~~~~~~~~
Install OPNFV-playground (the tool chain to deploy/test CI scenarios in fuel@opnfv, ):
-``3.2.1 Downgrade paramiko package from 2.x.x to 1.10.0``
+``1 Downgrade paramiko package from 2.x.x to 1.10.0``
The paramiko package 2.x.x doesn’t work with OPNFV-playground tool chain now, Jira ticket FUEL - 188 has been raised for the same.
Check paramiko package version by following below steps in your system:
-$ python
-Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
->>> import paramiko
->>> print paramiko.__version__
->>> exit()
+.. code:: bash
+
+ $ python
+ Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
+
+ >>> import paramiko
+ >>> print paramiko.__version__
+ >>> exit()
You will get the current paramiko package version, if it is 2.x.x, uninstall this version by
>>> exit()
-``3.2.2 Clone the fuel@opnfv``
+``2 Clone the fuel@opnfv``
Check out the specific version of specific branch of fuel@opnfv
$ git checkout stable/Danube
-``3.2.3 Creating the scenario``
+``3 Creating the scenario``
Implement the scenario file as described in 3.1.4
-``3.2.4 Deploying the scenario``
+``4 Deploying the scenario``
You can use the following command to deploy/test os-nosdn kvm_ovs_dpdk-(no)ha and os-nosdn-kvm_ovs_dpdk_bar-(no)ha scenario
Check $ ./ci_pipeline.sh -h for further information.
-3.3 Jenkins Project
-~~~~~~~~~~~~~~~~~~~
+Jenkins Project
+~~~~~~~~~~~~~~~
os-nosdn-kvm_ovs_dpdk-(no)ha and os-nosdn-kvm_ovs_dpdk_bar-(no)ha scenario can be executed from the jenkins project :
- HA scenarios:
+ ``HA scenarios:``
1. "fuel-os-nosdn-kvm_ovs_dpdk-ha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk-ha)
2. "fuel-os-nosdn-kvm_ovs_dpdk_bar-ha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-ha)
- NOHA scenarios:
- 1. "fuel-os-nosdn-kvm_ovs_dpdk-noha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk-noha)
- 2. "fuel-os-nosdn-kvm_ovs_dpdk_bar-noha-baremetal-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-noha)
+ ``NOHA scenarios:``
+ 1. "fuel-os-nosdn-kvm_ovs_dpdk-noha-virtual-daily-master" (os-nosdn-kvm_ovs_dpdk-noha)
+ 2. "fuel-os-nosdn-kvm_ovs_dpdk_bar-noha-virtual-daily-master" (os-nosdn-kvm_ovs_dpdk_bar-noha)
This chapter explains the procedure to configure the InfluxDB and Grafana on Node1 or Node2
depending on the testtype to publish KVM4NFV test results. The cyclictest cases are executed
and results are published on Yardstick Dashboard(Grafana). InfluxDB is the database which will
-store the cyclictest results and Grafana is a visualisation suite to view the maximum,minumum and
+store the cyclictest results and Grafana is a visualisation suite to view the maximum,minimum and
average values of the time series data of cyclictest results.The framework is shown in below image.
.. figure:: images/dashboard-architecture.png
**1. File**: Default Dispatcher module is file. If the dispatcher module is configured as a file,then the test results are stored in a temporary file yardstick.out
( default path: /tmp/yardstick.out).
-Dispatcher module of "Verify Job" is "Default". So,the results are stored in Yardstick.out file for verify job. Storing all the verify jobs in InfluxDB database causes redundancy of latency values. Hence, a File output format is prefered.
+Dispatcher module of "Verify Job" is "Default". So,the results are stored in Yardstick.out file for verify job.
+Storing all the verify jobs in InfluxDB database causes redundancy of latency values. Hence, a File output format is prefered.
.. code:: bash
max_bytes = 0
backup_count = 0
-**2. Influxdb**: If the dispatcher module is configured as influxdb, then the test results are stored in Influxdb. Users can check test resultsstored in the Influxdb(Database) on Grafana which is used to visualize the time series data.
+**2. Influxdb**: If the dispatcher module is configured as influxdb, then the test results are stored in Influxdb.
+Users can check test resultsstored in the Influxdb(Database) on Grafana which is used to visualize the time series data.
To configure the influxdb, the following content in /etc/yardstick/yardstick.conf need to updated
Detailing the dispatcher module in verify and daily Jobs:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-KVM4NFV updates the dispatcher module in the yardstick configuration file(/etc/yardstick/yardstick.conf) depending on the Job type(Verify/Daily). Once the test is completed, results are published to the respective dispatcher modules.
+KVM4NFV updates the dispatcher module in the yardstick configuration file(/etc/yardstick/yardstick.conf) depending on the Job type(Verify/Daily).
+Once the test is completed, results are published to the respective dispatcher modules.
Dispatcher module is configured for each Job type as mentioned below.
``Displaying Results on Grafana dashboard:``
-- Once the test results are stored in Influxdb, dashboard configuration file(Json) which used to display the cyclictest results on Grafana need to be created by following the `Grafana-procedure`_ and then pushed into `yardstick-repo`_
+- Once the test results are stored in Influxdb, dashboard configuration file(Json) which used to display the cyclictest results
+on Grafana need to be created by following the `Grafana-procedure`_ and then pushed into `yardstick-repo`_
- Grafana can be accessed at `Login`_ using credentials opnfv/opnfv and used for visualizing the collected test data as shown in `Visual`_\
1. Idle-Idle Graph
~~~~~~~~~~~~~~~~~~~~
-`Idle-Idle`_ graph displays the Average,Maximum and Minimum latency values obtained by running Idle_Idle test-type of the cyclictest. Idle_Idleimplies that no stress is applied on the Host or the Guest.
+`Idle-Idle`_ graph displays the Average, Maximum and Minimum latency values obtained by running Idle_Idle test-type of the cyclictest.
+Idle_Idle implies that no stress is applied on the Host or the Guest.
.. _Idle-Idle: http://testresults.opnfv.org/grafana/dashboard/db/kvmfornfv-cyclictest?panelId=10&fullscreen
2. CPU_Stress-Idle Graph
~~~~~~~~~~~~~~~~~~~~~~~~~
-`Cpu_Stress-Idle`_ graph displays the Average,Maximum and Minimum latency values obtained by running Idle_Idle test-type of the cyclictest. Idle_Idle implies that CPU stress is applied on the Host and no stress on the Guest.
+`Cpu_Stress-Idle`_ graph displays the Average, Maximum and Minimum latency values obtained by running Cpu-stress_Idle test-type of the cyclictest.
+Cpu-stress_Idle implies that CPU stress is applied on the Host and no stress on the Guest.
.. _Cpu_stress-Idle: http://testresults.opnfv.org/grafana/dashboard/db/kvmfornfv-cyclictest?panelId=11&fullscreen
3. Memory_Stress-Idle Graph
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-`Memory_Stress-Idle`_ graph displays the Average,Maximum and Minimum latency values obtained by running Idle_Idle test-type of the Cyclictest. Idle_Idle implies that Memory stress is applied on the Host and no stress on the Guest.
+`Memory_Stress-Idle`_ graph displays the Average, Maximum and Minimum latency values obtained by running Memory-stress_Idle test-type of the Cyclictest.
+Memory-stress_Idle implies that Memory stress is applied on the Host and no stress on the Guest.
.. _Memory_Stress-Idle: http://testresults.opnfv.org/grafana/dashboard/db/kvmfornfv-cyclictest?panelId=12&fullscreen
4. IO_Stress-Idle Graph
~~~~~~~~~~~~~~~~~~~~~~~~~
-`IO_Stress-Idle`_ graph displays the Average,Maximum and Minimum latency values obtained by running Idle_Idle test-type of the Cyclictest. Idle_Idle implies that IO stress is applied on the Host and no stress on the Guest.
+`IO_Stress-Idle`_ graph displays the Average, Maximum and Minimum latency values obtained by running IO-stress_Idle test-type of the Cyclictest.
+IO-stress_Idle implies that IO stress is applied on the Host and no stress on the Guest.
.. _IO_Stress-Idle: http://testresults.opnfv.org/grafana/dashboard/db/kvmfornfv-cyclictest?panelId=13&fullscreen
increase stress. Cyclictest will run on the guest VM that is launched on the same host, where the guest
is under no stress. It outputs Avg, Min and Max latency values.
-.. figure:: images/io-stress-test-type.png
+.. figure:: images/io-stress-idle-test-type.png
:name: io-stress-idle test type
:width: 100%
:align: center
.. http://creativecommons.org/licenses/by/4.0
=================
-PACKET FORWARDING
+Packet Forwarding
=================
About Packet Forwarding
| | - Implements three scenarios (Host/Guest/SRIOV) |
| | as part of testing in KVMFORNFV |
| Danube | - Uses automated test framework of OPNFV |
-| | VSWITCHPERF software (PVP/PVVP) |
-| | |
+| | VSWITCHPERF software (PVP/PVVP) |
| | - Works with IXIA Traffic Generator |
+-----------------------------+---------------------------------------------------+
For complete VSPERF documentation go to `link.`_
-.. _link.: http://artifacts.opnfv.org/vswitchperf/colorado/index.html
+.. _link.: http://artifacts.opnfv.org/vswitchperf/danube/index.html
Installation
Supported Hypervisors
~~~~~~~~~~~~~~~~~~~~~
-* Qemu version 2.3.
+* Qemu version 2.6.
Other Requirements
~~~~~~~~~~~~~~~~~~
script **systems/build_base_machine.sh**. It should be executed under
user account, which will be used for vsperf execution.
- **Please Note:** Password-less sudo access must be configured for given user
- before script is executed.
+ **Please Note:** Password-less sudo access must be configured for given user before script is executed.
Execution of installation script:
Installation
~~~~~~~~~~~~
-Follow the [installation instructions] to install.
+Follow the installation instructions to install.
On the CentOS 7 system
~~~~~~~~~~~~~~~~~~~~~~
support for Destination Network Address Translation (DNAT) for both the MAC and
IP addresses. l2fwd can be found in <vswitchperf_dir>/src/l2fwd
-.. figure:: images/Guest_Scenario.png
- :name: Guest_Scenario
- :width: 100%
- :align: center
-
-
Executing tests
~~~~~~~~~~~~~~~~
Raw virtual machine throughput performance can be measured by execution of PVP
test with direct access to NICs by PCI passthrough. To execute VM with direct
-access to PCI devices, enable vfio-pci_. In order to use virtual functions,
+access to PCI devices, enable vfio-pci. In order to use virtual functions,
SRIOV-support_ must be enabled.
Execution of test with PCI passthrough with vswitch disabled:
$ ./vsperf --conf-file=<path_to_custom_conf>/10_custom.conf \
--vswitch none --vnf QemuPciPassthrough pvp_tput
-Any of supported guest-loopback-application_ can be used inside VM with
+Any of supported guest-loopback-application can be used inside VM with
PCI passthrough support.
Note: Qemu with PCI passthrough support can be used only with PVP test
deployment.
-
-.. _guest-loopback-application:
| Mem Ch 3: Reads (MB/s): 6867.47 | Mem Ch 3: Reads (MB/s): 7403.66 |
| Writes(MB/s): 1805.53 | Writes(MB/s): 1950.95 |
| | |
-| NODE0 Mem Read (MB/s): 27478.96 | NODE1 Mem Read (MB/s): 29624.51 |
+| NODE0 Mem Read (MB/s) : 27478.96 | NODE1 Mem Read (MB/s) : 29624.51 |
| NODE0 Mem Write (MB/s): 7225.79 | NODE1 Mem Write (MB/s): 7811.36 |
-| NODE0 P. Write (T/s) : 214810 | NODE1 P. Write (T/s): 238294 |
-| NODE0 Memory (MB/s): 34704.75 | NODE1 Memory (MB/s): 37435.87 |
+| NODE0 P. Write (T/s) : 214810 | NODE1 P. Write (T/s) : 238294 |
+| NODE0 Memory (MB/s) : 34704.75 | NODE1 Memory (MB/s) : 37435.87 |
+---------------------------------------+---------------------------------------+
| - System Read Throughput(MB/s): 57103.47 |
| - System Write Throughput(MB/s): 15037.15 |
.. code:: bash
- git clone https://github.com/opcm/pcm
- cd pcm
- make
+ $ git clone https://github.com/opcm/pcm
+ $ cd pcm
+ $ make
In collect_MBWInfo Function,the below command is executed on the node which was collected to the logs
with the timestamp and testType.The function will be called at the begining of each testcase and
.. code:: bash
- pcm-memory.x 60 &>/root/MBWInfo/MBWInfo_${testType}_${timeStamp}
+ $ pcm-memory.x 60 &>/root/MBWInfo/MBWInfo_${testType}_${timeStamp}
where,
${testType} = verify (or) daily
Code Review / kvmfornfv.git / commitdiff