Unify TG and VNF names in infrastructure files
[yardstick.git] / docs / testing / user / userguide / 14-nsb-operation.rst
index 721dba9..941a0bb 100644 (file)
@@ -2,6 +2,16 @@
 .. License.
 .. http://creativecommons.org/licenses/by/4.0
 .. (c) OPNFV, 2016-2018 Intel Corporation.
+..
+    Convention for heading levels in Yardstick documentation:
+
+    =======  Heading 0 (reserved for the title in a document)
+    -------  Heading 1
+    ^^^^^^^  Heading 2
+    +++++++  Heading 3
+    '''''''  Heading 4
+
+    Avoid deeper levels because they do not render well.
 
 Yardstick - NSB Testing - Operation
 ===================================
@@ -89,9 +99,9 @@ Availability zone
 ^^^^^^^^^^^^^^^^^
 
 The configuration of the availability zone is requred in cases where location
-of exact compute host/group of compute hosts needs to be specified for SampleVNF
-or traffic generator in the heat test case. If this is the case, please follow
-the instructions below.
+of exact compute host/group of compute hosts needs to be specified for
+:term:`SampleVNF` or traffic generator in the heat test case. If this is the
+case, please follow the instructions below.
 
 .. _`Create a host aggregate`:
 
@@ -105,7 +115,8 @@ the instructions below.
    .. code-block:: bash
 
      # create host aggregate
-     openstack aggregate create --zone <AZ_NAME> --property availability_zone=<AZ_NAME> <AGG_NAME>
+     openstack aggregate create --zone <AZ_NAME> \
+       --property availability_zone=<AZ_NAME> <AGG_NAME>
      # show available hosts
      openstack compute service list --service nova-compute
      # add selected host into the host aggregate
@@ -125,7 +136,7 @@ the instructions below.
        image: yardstick-samplevnfs
        ...
        servers:
-         vnf__0:
+         vnf_0:
            ...
            availability_zone: <AZ_NAME>
            ...
@@ -136,8 +147,9 @@ the instructions below.
        networks:
          ...
 
-There are two example of SampleVNF scale out test case which use the availability zone
-feature to specify the exact location of scaled VNFs and traffic generators.
+There are two example of SampleVNF scale out test case which use the
+``availability zone`` feature to specify the exact location of scaled VNFs and
+traffic generators.
 
 Those are:
 
@@ -164,21 +176,19 @@ Those are:
      |  5 | agg1 | AZ_NAME_1         |
      +----+------+-------------------+
 
-2. If no host aggregates are configured, please use `steps above`__ to
-   configure them.
+2. If no host aggregates are configured, please follow the instructions to
+   `Create a host aggregate`_
 
-__ `Create a host aggregate`_
 
-
-3. Run the SampleVNF PROX scale-out test case, specifying the availability
-   zone of each VNF and traffic generator as a task arguments.
+3. Run the SampleVNF PROX scale-out test case, specifying the
+   ``availability zone`` of each VNF and traffic generator as task arguments.
 
    .. note:: The ``az_0`` and ``az_1`` should be changed according to the host
-     aggregates created in the OpenStack.
+      aggregates created in the OpenStack.
 
    .. code-block:: console
 
-     yardstick -d task start\
+     yardstick -d task start \
      <repo>/samples/vnf_samples/nsut/prox/tc_prox_heat_context_l2fwd_multiflow-2-scale-out.yaml\
        --task-args='{
          "num_vnfs": 4, "availability_zone": {
@@ -198,7 +208,7 @@ Collectd KPIs
 -------------
 
 NSB can collect KPIs from collected.  We have support for various plugins
-enabled by the Barometer project.
+enabled by the :term:`Barometer` project.
 
 The default yardstick-samplevnf has collectd installed. This allows for
 collecting KPIs from the VNF.
@@ -208,12 +218,11 @@ We assume that collectd is not installed on the compute nodes.
 
 To collectd KPIs from the NFVi compute nodes:
 
-
     * install_collectd on the compute nodes
     * create pod.yaml for the compute nodes
     * enable specific plugins depending on the vswitch and DPDK
 
-    example pod.yaml section for Compute node running collectd.
+    example ``pod.yaml`` section for Compute node running collectd.
 
 .. code-block:: yaml
 
@@ -323,8 +332,8 @@ Baremetal
        traffic_profile: ../../traffic_profiles/ipv4_throughput.yaml
        topology: vfw-tg-topology.yaml
        nodes:
-         tg__0: trafficgen_1.yardstick
-         vnf__0: vnf.yardstick
+         tg__0: trafficgen_0.yardstick
+         vnf__0: vnf_0.yardstick
        options:
          framesize:
            uplink: {64B: 100}
@@ -356,8 +365,8 @@ Scale-Out
 
 VNFs performance data with scale-out helps
 
-  * in capacity planning to meet the given network node requirements
-  * in comparison between different VNF vendor offerings
+  * capacity planning to meet the given network node requirements
+  * comparison between different VNF vendor offerings
   * better the scale-out index, provides the flexibility in meeting future
     capacity requirements
 
@@ -418,7 +427,7 @@ options section.
   scenarios:
     - type: NSPerf
       nodes:
-        tg__0: tg_0.yardstick
+        tg__0: trafficgen_0.yardstick
 
       options:
         tg_0:
@@ -434,6 +443,43 @@ There two types of Standalone contexts available: OVS-DPDK and SRIOV.
 OVS-DPDK uses OVS network with DPDK drivers.
 SRIOV enables network traffic to bypass the software switch layer of the Hyper-V stack.
 
+Emulated machine type
+^^^^^^^^^^^^^^^^^^^^^
+
+For better performance test results of emulated VM spawned by Yardstick SA
+context (OvS-DPDK/SRIOV), it may be important to control the emulated machine
+type used by QEMU emulator. This attribute can be configured via TC definition
+in ``contexts`` section under ``extra_specs`` configuration.
+
+For example:
+
+.. code-block:: yaml
+
+  contexts:
+     ...
+     - type: StandaloneSriov
+       ...
+       flavor:
+         ...
+         extra_specs:
+           ...
+           machine_type: pc-i440fx-bionic
+
+Where, ``machine_type`` can be set to one of the emulated machine type
+supported by QEMU running on SUT platform. To get full list of supported
+emulated machine types, the following command can be used on the target SUT
+host.
+
+.. code-block:: yaml
+
+  # qemu-system-x86_64 -machine ?
+
+By default, the ``machine_type`` option is set to ``pc-i440fx-xenial`` which is
+suitable for running Ubuntu 16.04 VM image. So, if this type is not supported
+by the target platform or another VM image is used for stand alone (SA) context
+VM (e.g.: ``bionic`` image for Ubuntu 18.04), this configuration should be
+changed accordingly.
+
 Standalone with OVS-DPDK
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -451,11 +497,11 @@ Default values for OVS-DPDK:
 Sample test case file
 ^^^^^^^^^^^^^^^^^^^^^
 
-  1. Prepare SampleVNF image and copy it to ``flavor/images``.
-  2. Prepare context files for TREX and SampleVNF under ``contexts/file``.
-  3. Add bridge named ``br-int`` to the baremetal where SampleVNF image is deployed.
-  4. Modify ``networks/phy_port`` accordingly to the baremetal setup.
-  5. Run test from:
+1. Prepare SampleVNF image and copy it to ``flavor/images``.
+2. Prepare context files for TREX and SampleVNF under ``contexts/file``.
+3. Add bridge named ``br-int`` to the baremetal where SampleVNF image is deployed.
+4. Modify ``networks/phy_port`` accordingly to the baremetal setup.
+5. Run test from:
 
 .. literalinclude:: /../samples/vnf_samples/nsut/acl/tc_ovs_rfc2544_ipv4_1rule_1flow_64B_trex.yaml
    :language: yaml