TeraVM Chassis 2G shell

[Quali-Community]

TeraVM Chassis 2G shell

A shell integrates a device model, application or other technology with CloudShell. A shell consists of a data model that defines how the device and its properties are modeled in CloudShell, along with automation that enables interaction with the device via CloudShell.

Traffic Generator Shells

CloudShell's traffic generator shells enable you to conduct traffic test activities on Devices Under Test (DUT) or Systems Under Test (SUT) from a sandbox. In CloudShell, a traffic generator is typically modeled using a chassis resource, which represents the traffic generator device and ports, and a controller service that runs the chassis commands, such as Load Configuration File, Start Traffic and Get Statistics. Chassis and controllers are modeled by different shells, allowing you to accurately model your real-life architecture. For example, scenarios where the chassis and controller are located on different machines.

For additional information on traffic generator shell architecture, and setting up and using a traffic generator in CloudShell, see the Traffic Generators Overiew online help topic.

Tera VM Shells

TeraVM shells provide you with connectivity and management capabilities such as device structure discovery and power management for the TeraVM traffic generator.

For more information on the TeraVM Chassis and Controller, see the official TeraVM product documentation.

To model a TeraVM traffic generator in CloudShell, you must use the following shells:

▪ TeraVM Chassis 2G Shell, which provides data model and autoload functionality to model and load the TeraVM to resource management.

▪ TeraVM Controller 2G Shell (service), which provides automation commands to run on the TeraVM Chassis, such as Load Configuration, Start Traffic, Get Results.

Standard version

The TeraVM shells are based on the Traffic Shell Standard version 1.0.0.

For detailed information about the shell’s structure and attributes, see the Traffic Shell standard in GitHub.

Requirements

Release: TeraVM Shells

▪ TeraVM version: 13.4

▪ CloudShell version: 8.0 and above

Shell Documentation

The shell documentation can be found at: TeraVM Chassis 2G Shell ReadMe.

Repository	Latest Release	README.md
Name TeraVM-Chassis-Shell-2G Owner QualiSystems Type 2nd Gen Shell Category Traffic Generators Min. Compatible CloudShell Version 8.0 Total Downloads (All Releases) 36	Link 1.0.1 (Version / Tag) TAR / ZIP 1.0.1 (TAR) 1.0.1 (ZIP) Author anthony-poddubny Published On 11/07/2018 10:07 AM Assets TeraVM.Chassis.Shell.2G.zip [6 KB]	TeraVM Shells Release date: December 2017 Shell version: 1.0.0 Document version: 1.0 In This Guide Overview Downloading the Shell Importing and Configuring the Shell Updating Python Dependencies for Shells Typical Workflows References Release Notes Overview A shell integrates a device model, application or other technology with CloudShell. A shell consists of a data model that defines how the device and its properties are modeled in CloudShell, along with automation that enables interaction with the device via CloudShell. Traffic Generator Shells CloudShell's traffic generator shells enable you to conduct traffic test activities on Devices Under Test (DUT) or Systems Under Test (SUT) from a sandbox. In CloudShell, a traffic generator is typically modeled using a chassis resource, which represents the traffic generator device and ports, and a controller service that runs the chassis commands, such as Load Configuration File, Start Traffic and Get Statistics. Chassis and controllers are modeled by different shells, allowing you to accurately model your real-life architecture. For example, scenarios where the chassis and controller are located on different machines. For additional information on traffic generator shell architecture, and setting up and using a traffic generator in CloudShell, see the Traffic Generators Overiew online help topic. Tera VM Shells TeraVM shells provide you with connectivity and management capabilities such as device structure discovery and power management for the TeraVM traffic generator. For more information on the TeraVM Chassis and Controller, see the official TeraVM product documentation. To model a TeraVM traffic generator in CloudShell, you must use the following shells: ▪ TeraVM Chassis 2G Shell, which provides data model and autoload functionality to model and load the TeraVM to resource management. ▪ TeraVM Controller 1G Shell (service), which provides automation commands to run on the TeraVM Chassis, such as Load Configuration, Start Traffic, Get Results. Standard version The TeraVM shells are based on the Traffic Shell Standard version 1.0.0. For detailed information about the shell’s structure and attributes, see the Traffic Shell standard in GitHub. Requirements Release: TeraVM Shells ▪ TeraVM version: 13.4 ▪ CloudShell version: 7.0 and above Note: If your CloudShell version does not support this shell, you should consider upgrading to a later version of CloudShell or contact customer support. Data Model The shell's data model includes all shell metadata, families, and attributes. TeraVM Chassis Families and Models The chassis families and models are listed in the following table: Family Model Description Traffic Generator Chassis TeraVM Chassis TeraVM Chassis Module Generic Traffic Generator Module Modules located on the chassis Port Generic Traffic Generator Port Generic Traffic Generator Port TeraVM Chassis Attributes The chassis attribute names and types are listed in the following table: Attribute Type Default value Description Name String CloudShell resource display name. Address String Root Resource address (address of the device). Folder String Root CloudShell folder to place the resource. Use the search bar to quickly find the resource. Visibility Lookup Family Default (Everyone) Visibility determines who can see the resource in the diagram, search pane, and Inventory dashboard. By default, visibility is defined in the resource family and can be changed for a specific resource. Possible values: Family Default (Everyone), Admin only, and Everyone. Remote Connection Lookup Family Default (Enable) Remote connection determines if you can remotely connect to the resource. By default, the remote connection is defined in the resource family and can be changed for a specific resource. Possible values: Family Default (Enable), Enable, and Disable. User String Admin user on the device. Password Password Password for Admin user on the device. Controller TCP Port String 443 TCP port of the traffic server. Relevant only in case an external server is configured. If left empty, default TCP port should be used. Controller Address String IP address of the traffic server. Relevant only in case an external server is configured. Client Install Path String Path in which the traffic client is installed on the Execution Server. Power Management Boolean True Used by the power management orchestration, if enabled, to determine whether to automatically manage the device's power status. Serial Number String Serial number of the device. Server Description String Full description of the server. Usually includes the OS, exact firmware version, and additional characteristics of the device. Model Name String Catalog name of the device model. This attribute will be displayed in CloudShell instead of the CloudShell model. Vendor String Vendor name. Version String Firmware version of the resource. TeraVM Controller Attributes The controller attribute names and types are listed in the following table: Attribute Type Description Client Install Path String Path in which the traffic client is installed on the Execution Server. For example C:/Program Files (86)/Ixia/Ixos/6.90EA. Controller TCP Port String TCP port of the traffic server. Relevant only in case an external server is configured. If left empty, default TCP port is used. Password Password Test Files Location String Location for test related files. Test User String TeraVM Test User for Open Automation Authorization. Test User Password Password TeraVM Test User Password for Open Automation Authorization. User String Automation This section describes the automation (drivers or scripts) associated with the data model. The shell’s driver is provided as part of the shell package. There are two types of automation processes, Autoload and Resource. Autoload is executed when creating the resource in the Inventory dashboard, while resource commands are run in the sandbox. For Traffic Generator shells, commands are configured and executed from the controller service in the sandbox, with the exception of the Autoload command, which is executed when creating the resource. TeraVM Chassis Command Description Autoload Discovers all switches, modules and leaf ports (free ports that can be used for connections) connected to the controller. It adds them as child resources for the current resource. TeraVM Controller Command Description Load Configuration Loads the configuration file and reserves necessary ports. * TeraVM config file (String) (Mandatory): The configuration file name. Path should include the protocol type, for example tftp://10.10.10.10/asdf. * Use ports from reservation (Enum): True or False. Updates the configuration file with ports from the current reservation based on their Logical Name attributes. Start Traffic Starts a test with the current configuration. Stop Traffic Stops running the test. Get Results Gets the test result file and attaches it to the reservation. Downloading the Shell The TeraVM shells are available from the Quali Community Integrations page. Download the files into a temporary location on your local machine. The shells comprise: File name Description TeraVM_Chassis_Shell_Package.zip TeraVM Chassis shell package TeraVM_Controller_Shell_Package.zip TeraVM Controller shell package teravm-offline-dependencies-1.0.0.zip Shell Python dependencies (for offline deployments only) Cleanup Reservation.zip Teardown script for cleaning a reservation. Importing and Configuring the Shells This section describes how to import the TeraVM shells and configure and modify the shell’s devices. Importing the shells into CloudShell To import the TeraVM Controller 1G shell into CloudShell: Make sure you have the shell’s zip package. If not, download the shell from the Quali Community's Integrations page. Backup your database. Log in to CloudShell Portal as administrator of the relevant domain. In the user menu, select Import Package. In the dialog box, navigate to the shell's zip package, select it and click Open. The shell is displayed in the App/Service page. To import the TeraVM Chassis 2G shell into CloudShell: Make sure you have the shell’s zip package. If not, download the shell from the Quali Community's Integrations page. In CloudShell Portal, as Global administrator, open the Manage – Shells page. Click Import. In the dialog box, navigate to the shell's zip package, select it and click Open. The shell is displayed in the Shells page and can be used by domain administrators in all CloudShell domains to create new inventory resources, as explained in Adding Inventory Resources. Offline installation of a shell Note: Offline installation instructions are relevant only if CloudShell Execution Server has no access to PyPi. You can skip this section if your execution server has access to PyPi. For additional information, see the online help topic on offline dependencies. In offline mode, import the shell into CloudShell and place any dependencies in the appropriate dependencies folder. The dependencies folder may differ, depending on the CloudShell version you are using: For CloudShell version 8.3 and above, see Adding Shell and script packages to the local PyPi Server repository. For CloudShell version 8.2, perform the appropriate procedure: Adding Shell and script packages to the local PyPi Server repository or Setting the python pythonOfflineRepositoryPath configuration key. For CloudShell versions prior to 8.2, see Setting the python pythonOfflineRepositoryPath configuration key. Adding shell and script packages to the local PyPi Server repository If your Quali Server and/or execution servers work offline, you will need to copy all required Python packages, including the out-of-the-box ones, to the PyPi Server's repository on the Quali Server computer (by default C:\Program Files (x86)\QualiSystems\CloudShell\Server\Config\Pypi Server Repository). For more information, see Configuring CloudShell to Execute Python Commands in Offline Mode. To add Python packages to the local PyPi Server repository: If you haven't created and configured the local PyPi Server repository to work with the execution server, perform the steps in Add Python packages to the local PyPi Server repository (offlinemode). For each shell or script you add into CloudShell, do one of the following (from an online computer): Connect to the Internet and download each dependency specified in the requirements.txt file with the following command: pip download -r requirements.txt. The shell or script's requirements are downloaded as zip files. In the Quali Community's Integrations page, locate the shell and click the shell's Download link. In the page that is displayed, from the Downloads area, extract the dependencies package zip file. Place these zip files in the local PyPi Server repository. Setting the python PythonOfflineRepositoryPath configuration key Before PyPi Server was introduced as CloudShell’s python package management mechanism, the PythonOfflineRepositoryPath key was used to set the default offline package repository on the Quali Server machine, and could be used on specific Execution Server machines to set a different folder. To set the offline python repository: Download the teravm-offline-dependencies-1.0.0.zip file, see Downloading the Shell. Unzip it to a local repository. Make sure the execution server has access to this folder. On the Quali Server machine, in the ~\CloudShell\Server\customer.config file, add the following key to specify the path to the default python package folder (for all Execution Servers): <add key="PythonOfflineRepositoryPath" value="repository full path"/> If you want to override the default folder for a specific Execution Server, on the Execution Server machine, in the ~TestShell\Execution Server\customer.config file, add the following key: <add key="PythonOfflineRepositoryPath" value="repository full path"/> Restart the Execution Server. Configuring a new resource This section explains how to create a new resource from the shell. In CloudShell, the component that models the device is called a resource. It is based on the shell that models the device and allows the CloudShell user and API to remotely control the device from CloudShell. You can also modify existing resources, see Managing Resources in the Inventory. To create a resource for the TeraVM Chassis 2G shell device: In the CloudShell Portal, in the Inventory dashboard, click Add New. From the list, select TeraVM Chassis shell. Enter the Name and IP address of the TeraVM Chassis. Click Create. In the Resource dialog box, edit the following Resource Details: Controller TCP Port: The TCP port of the traffic server. Relevant only in case an external server is confiugured. Default TCP port should be used if kept empty. Click Continue. CloudShell validates the device’s settings and updates the new resource with the device’s structure. Updating Python Dependencies for Shells This section explains how to update your Python dependencies folder. This is required when you upgrade a shell that uses new/updated dependencies. It applies to both online and offline dependencies. Updating offline Python dependencies To update offline Python dependencies: Download the latest Python dependencies package zip file locally. Extract the zip file to the suitable offline package folder(s). Terminate the shell’s instance, as explained here. Updating online Python dependencies In online mode, the execution server automatically downloads and extracts the appropriate dependencies file to the online Python dependencies repository every time a new instance of the driver or script is created. To update online Python dependencies: If there is a live instance of the shell's driver or script, terminate the shell’s instance, as explained here.. If an instance does not exist, the execution server will download the Python dependencies the next time a command of the driver or script runs. Typical Workflows Workflow 1 - Creating a new blueprint Create a new blueprint. Log in to CloudShell Portal and create a new blueprint (Blueprint Catalog>Create Blueprint). Give the blueprint a name. Add resources and services to the blueprint. Click the Resource button and add the TeraVM Chassis resource and all needed ports into the diagram. Associate the port sub resources with the TeraVM interfaces, by specifying the port attribute Logical Name. Click the App/Services tab and add the TeraVMController service. Add the teardown script Cleanup Reservation.zip, provided with the shell, see Downloading the Shell. This script runs the cleanup_reservation driver command when the reservation ends and releases ports which were used by the reservation. Go to the Scripts management page Manage>Scripts>Blueprint, click Add New Script and choose the Cleanup Reservation.zip file. Click Edit for the newly added script and change Script Type to Teardown. Return to the blueprint and open properties, Blueprint>Properties. In the Driver section, select Python Setup & Teardown, add Estimated teardown duration 1 min. Click Add Script and choose Cleanup Reservation from the list. Click Update to save changes. Workflow 2 - Running a test Reserve a blueprint that is configured to run traffic tests, like the one configured in Workflow 1. From the TeraVMController service, run the Load Configuration command. Hover over the TeraVMController service and click Commands. In the Resource Commands pane, click the Load Configuration command. In the TeraVM config file input, specify the path to your test configuration file. It can be a full path, or relative path under the location specified in the attribute Test Files Location, such as <reservation_id>/test_group.xml or only test_group.xml. Make sure the path is accessible to the Execution Server running the command. Click Run, to load the test configuration to the TeraVM Controller. Run the Start Test command. Run the Stop Test command. Get the test's result file. Run the Get Result command. The test's result file is attached to the sandbox. References To download and share integrations, see Quali Community's Integrations. For instructional training and documentation, see Quali University. To suggest an idea for the product, see Quali's Idea box. To connect with Quali users and experts from around the world, ask questions and discuss issues, see Quali's Community forums. To use traffic generator ports as abstract resources, see CloudShell's Online Help. Release Notes What's New For release updates, see the shell's GitHub releases page as follows: ▪ TeraVM Chassis 2G Shell Releases ▪ TeraVM Controller 1G Shell Releases
* Updated Weekly	* Update Now	* Repository, release and asset info is updated weekly. * Please allow 30-60 seconds for manual update changes to take effect.

---

 Gal Cohen 01/24/2018 10:18 AM

·  3286  ·