Installing a Test Agent on virtualization platforms

This page gives an overview of how you can deploy a Netrounds Test Agent on some popular hypervisor platforms. The various Test Agent images are provided either directly from Netrounds or from your NFV orchestration partner. Full information is found in separate technical guides, available at https://portal.netrounds.com.

It may be noted that the RAW format can be converted to a variety of other formats using appropriate tools. If you have specific questions on this topic, please contact Netrounds technical support at support@netrounds.com. The Test Agent RAW image may be seen as a replacement for the ISO image which was provided in certain older Netrounds versions.

  • OpenStack/KVM: For this you need a Test Agent software disk image in RAW or QCOW2 format. You upload the Test Agent image to OpenStack and launch an instance of it, either through the OpenStack Horizon user interface (with or without a Heat Orchestration Template, HOT) or by means of a Python script using OpenStack Python APIs. HTTP Get or config-drive is used to transfer user data into the virtual machine running the vTA to provide day-0 configuration and information on how to connect to Netrounds Control Center (domain name/IP address and port).
  • VMware/vSphere: For this you need a Test Agent software disk image in OVA format. You upload the Test Agent image to vSphere and start a Test Agent vApp in VMware. Configuration of user data is done via the vSphere web client or directly in the OVF file.
  • VirtualBox: For this you need a Test Agent software disk image in OVA format. User data is not supported in VirtualBox, which means that you have to register the Test Agent manually to Netrounds Control Center using the console once the Test Agent has booted.
  • Amazon Web Services (AWS): For this you need a Test Agent AMI (Amazon Machine Image), a special type of virtual appliance used to create a virtual machine within the Amazon Elastic Compute Cloud (“EC2”).
  • Google Cloud (GCP): For this you need a Test Agent image in format *.gcp.tar.gz, which can be deployed on the Google Cloud platform.
  • Azure: For this you need a Test Agent software disk image in VHD format, which can be deployed in the Microsoft Azure cloud computing service.

Format of “cloud-config” metadata

On certain virtualization platforms, including OpenStack and AWS, “cloud-config” metadata must be entered specifying among other things how to connect to Netrounds Control Center. The format of this metadata is given below.

Basic configuration:

Note

The #cloud-config and netrounds_test_agent lines must be present, and all of the remaining lines must be indented.

#cloud-config
netrounds_test_agent:
  name: MyvTA                                # vTA name
  email: john.doe@example.com                # NCC user email
  password: secret                           # NCC user password
  account: theaccount                        # NCC account (short name, found in NCC URL)
  server: <login-server>:443                 # NCC host and port (default == SaaS)
                                             #   Note: With an IPv6 server address the whole string
                                             #         including port must be in double quotes
  admin_password: secret                     # Admin user password. Use null to disable.
  root_password: secret                      # Menu root shell access password. Use null to disable.
                                             #
  management_interface: eth0                 # Test Agent management interface
  management_mtu: 1500                       # MTU on management interface
  management_address_type: dhcp              # Can be "dhcp" or "static"

  ## Set the following if using "static" above:
  # management_ip: 192.168.1.2/24
  # management_dns: 8.8.8.8, 8.8.4.4
  # management_default_gateway: 192.168.1.1
  # management_ntp: ntp.netrounds.com

  ## Set the following if using an HTTP proxy:
  # http_proxy: myproxy.lan
  # http_proxy_port: 80
  # http_proxy_auth_type: none               # Can be "none" or "basic"
  # http_proxy_username: johndoe
  # http_proxy_password: secret

  ## Note: IPv6 management requires special config, see separate documentation
  # management_enable_ipv6: False
  # management_ntp_allow_ipv6: False
  # management_address6_type: none           # Can be "dhcp", "slaac", or "static"

  ## Set if "static". Note: Use CIDR format for IP
  # management_ip6: 2001:db8:85a3::8a2e:370:7334/64
  # management_dns6: 2001:4860:4860::8888, 2001:4860:4860::8844
  # management_default_gateway6: <gateway IP address>

The parameters management_ipmanagement_ntp are required only if management_address_type is “static”.

The parameters http_proxyhttp_proxy_auth_type are required only if the vTA is connecting to the server through an HTTP proxy.

The parameters http_proxy_username and http_proxy_password are required only if http_proxy_auth_type is “basic”.

The parameters management_enable_ipv6management_default_gateway6 are required only if IPv6 is used on the vTA management connection.

The parameters admin_password and root_password expect unicode strings. The passwords can be text or a salted hash. They are optional. The system would revert to default behaviour, if these parameters are absent.

Interface assignment in a hypervisor

When a vTA is provisioned in a hypervisor, its interfaces are numbered in ascending order according to the hypervisor PCI IDs. That is, the interface with the lowest PCI ID will be called eth0, the next will be called eth1, etc.

Later on, however, an interface will keep its name even if its PCI ID changes, or if other interfaces are added or removed.

Hardware requirements

The compute resources available to the virtual Test Agent will impact its performance. Hardware requirements for virtual Test Agents are found in the Test Agents data sheet; go to this page to download it.

Notes on hypervisor resource management

Most hypervisors have a resource manager for sharing the underlying hardware among all host VMs. These resources are basically CPU, storage I/O, and network bandwidth. For more deterministic behavior, SR-IOV and CPU pinning can be considered, but that is not required for the Netrounds Test Agent.

Please be aware that the resource manager may throttle some parameters, such as network bandwidth. To give just one example, the VM might think it has access to a 1 Gbit/s port, whereas the throttling only allows 80 Mbit/s throughput.