Installing a Test Agent Appliance on virtualization platforms: Introduction¶
This page gives an overview of how you can deploy a Test Agent on some popular hypervisor platforms. The various Test Agent images are provided either directly from Paragon Active Assurance or from your NFV orchestration partner. You upload and boot the Test Agent from the virtualization platform, and the Test Agent will automatically connect to Control Center.
Full information on how to do the deployment is found on separate pages:
A generic description of the virtual Test Agent VNF is given here.
Requirements on Test Agent disk image format differ between platforms, as detailed below.
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”).
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.
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.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 Control Center (domain name/IP address and port).
Oracle Cloud: For this you need a Test Agent software disk image in QCOW2 or VMDK format, which can be deployed on the Oracle Cloud platform.
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 Control Center using the console once the Test Agent has booted.
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.
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 Juniper Networks technical support at https://support.juniper.net/support/requesting-support. The Test Agent RAW image may be seen as a replacement for the ISO image which was provided in certain older (Netrounds) product versions.
Format of “cloud-config” metadata¶
On certain virtualization platforms, including AWS and OpenStack, “cloud-config” metadata must be entered specifying among other things how to connect to Control Center. The format of this metadata is given below.
Basic configuration:
Note
The #cloud-config and paa_test_agent lines must be present, and all of the remaining lines must be indented.
#cloud-config
paa_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>:<port> # NCC host and port
# Default == SaaS: login.netrounds.com:443
# On-prem default port is 6000, e.g. my.server.me:6000
# 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: time.google.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_ip … management_ntp are required only if management_address_type is “static”.
The parameters http_proxy … http_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_ipv6 … management_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. If these parameters are absent, the system will revert to its default behavior.
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 stated in the Test Agents datasheet; it is found at https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000684-en.pdf.
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 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.