Installation considerations for DevOps Test Virtualization Control Panel

You can install HCL DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) as part of HCL DevOps Test Workbench (Test Workbench), HCL DevOps Test Virtualization (Test Virtualization), or HCL DevOps Test Integrations and APIs (Test Integrations and APIs).

Consider the following information before you install Test Virtualization Control Panel.

Hardware and software requirements

For a complete list of system requirements, see System Requirements for DevOps Test Integrations and APIs 2024.03 (11.0.1).

Networking considerations

Note if Test Virtualization Control Panel will be running in an IPv4 or IPv6 networking environment. The server Networking installation option is used to declare an IPv4 or IPv6 addressing preference.
Note: The Test Virtualization Control Panel Networking installation option applies to Windows™ only.
Note: Accessing the Test Virtualization Control Panel web UI by using an IPv6 literal address is not supported.

Security considerations

Starting from version 9.1.1 onwards, when you install Test Virtualization Control Panel software, all communications with Test Virtualization Control Panel are secure and by default use HTTPS on port 5443. You can change the port number after installation and also enable plain HTTP as required. For details, see Configuring the server HTTP Endpoint.

For security considerations for installing the software in detail, see Security considerations for DevOps Test Virtualization Control Panel.

Installation considerations for the HTTP/TCP proxy

Before you deploy the HTTP/TCP proxy, it is important to consider the following items:
  • Network segments.
  • The proximity of the HTTP/TCP proxy to client and server applications because all traffic goes from client applications to the proxy and then to the server applications.
  • Systems that use HTTPS are sometimes locked down to accept communications from a specific source only, which could force the location of the HTTP/TCP proxy to be the same as the client applications.

Before you uninstall the HTTP/TCP proxy, copy the registration.xml file (which contains the Test Virtualization Control Panel location, HTTPS set up, and forwarding rules) so that these values can be reapplied after upgrading the proxy to the latest version. After you install server, upgrade the existing Test Virtualization Control Panel JDBC driver installations by copying the new driver over the existing files.

Security model planning

Test Virtualization Control Panel has a simple security model. The features available within server depend on the security model chosen during installation.

The following table describes the security model options.

Security Model Option Description
Active Directory Test Virtualization Control Panel uses one or more Active Directory servers to authenticate the user name and password provided by each user. This process enables you to use your Windows™ domain user names to log in to Test Virtualization Control Panel. However, Test Virtualization Control Panel does not store or maintain any user name and password information itself.

For an Active Directory server, only the Security group type (groupType=-2147483643) is supported. To use other group types, you must treat the server as an LDAP server and set up the user and group filters to match the appropriate attributes.

You must create two Active Directory groups:

  • Test Virtualization Control Panel "normal" users who are allowed to log in to Test Virtualization Control Panel but have limited access.
  • Test Virtualization Control Panel administrators.

Active Directory users must be put into these Active Directory groups and the names of these two groups must be specified in the fields provided on the Test Virtualization Control Panel Security Configuration screen in the Test Virtualization Control Panel installation program.
Lightweight Directory Access Protocol (LDAP) This option is similar to the Active Directory security model option but it authenticates against a single LDAP server. However, the basic approach of having two groups defined for user and administrators is the same.

Even when you are using an LDAP URL as an Active Directory server, you must select "Active Directory" as the LDAP provider in the LDAP list box, and then, specify the host name or IP address and port number of the LDAP server to use.
Test Virtualization Control Panel Built-in User names and passwords are managed by the Test Virtualization Control Panel and each user must enter a user name and password to log in. Thus, only authenticated users can control the Test Virtualization environment.

In addition, users who are identified as administrators can create other users. However, you must enter a user name and password for the first user, who will be created as an administrator. After Test Virtualization Control Panel is installed, you can log in as the administrator and create additional users.

None There is no user authentication. Users are not required to log in (by using a user name and password), which means that anyone who knows the Test Virtualization Control Panel URL can control, say, the Service Virtualization environment.

Before installing Test Virtualization Control Panel, it is important to consider whether and how you want Test Virtualization Control Panel to authenticate users:

  • To use either Active Directory or LDAP, you need the assistance of an Active Directory or LDAP administrator.
  • If your organization does not have any Active Directory or LDAP servers or if you are unsure about the configuration details of any such servers in your organization, you can use the Test Virtualization Control Panel Built-in authentication-type.

Working with Test Virtualization Control Panel workspace

The workspace is the directory where Test Virtualization Control Panel stores its data (for example, published stubs), which is separate from the installation directory.

The workspace contains the following databases that store data:
  • db.mv stores data about domains, environments, scenarios, or stubs.
  • sch_db.mv stores data about scheduled tests or Suites.
  • kairosdb.mv stores data about metrics collated by the KairosDB.
Note: You can find the data about the projects that contain published stubs in the repository sub folder for each of the domains to which the stubs were published.

The Test Virtualization Control Panel workspace contains numerous files that represent the overall configuration and the current state of Test Virtualization Control Panel along with data stored in the databases.

To prevent loss of data from the workspace, you must ensure that you set up a suitable backup strategy and periodically back up the workspace.
Remember: You must stop Test Virtualization Control Panel and wait until all processes are stopped before you can backup the workspace.

Rolling back of Test Virtualization Control Panel

When you want to roll back from Test Virtualization Control Panel 10.2.2 or earlier, to a previous version by using IBM® Installation Manager, you must have used Installation Manager to upgrade from an earlier version to a later version up to 10.2.2. The files of the earlier version must be available so that Installation Manager can access them for the roll back operation. Because Installation Manager supports rolling back the Test Virtualization Control Panel installation directory, but not the workspace directory, hence, you must manually roll back the workspace while rolling back the installation.
Note: When you roll back an Test Virtualization Control Panel version, the workspace cannot be reused and must be reinstalled.
Before you upgrade Test Virtualization Control Panel 10.2.2 or an earlier version to 10.2.3 or later, by using Installation Manager, you must take a back up of the workspace if you want to roll back to the earlier version and reuse the workspace of the earlier version. Because when you upgrade Test Virtualization Control Panel 10.2.2 or an earlier version to 10.2.3 or later, by using Installation Manager and select the workspace, the data contained in the workspace is automatically migrated to be supported in 10.2.3 or later. The migration of the workspace to 10.2.3 or later, renders it incompatible with 10.2.2 or an earlier version.
Restriction: You cannot use Installation Manager to roll back from 10.2.3 or later, to 10.2.2 or an earlier version. Also, if the workspace was migrated by Installation Manager during the upgrade, you cannot reuse the migrated workspace with your earlier version of Test Virtualization Control Panel.

Reusing the workspace

To determine the workspace location, open the container.server.properties file that is available in C:\Program Files\HCL\DevOpsTestControlPanel\usr\servers\defaultServer\apps\RTCP.war\WEB-INF\classes directory. Look for the line that contains the workingDirectory key. For example:
  • On Windows, workingDirectory=C:\HCL\HQS-Workspace
  • Non-Windows, workingDirectory=/var/hqs
Note: If you delete the workspace during the uninstallation of Test Virtualization Control Panel (by selecting the Delete Workspace option) in the Installation Manager, all the published test reports are deleted as well.
Before you upgrade or uninstall an older version to move to a newer version (when the upgrade is not applicable), perform the following tasks:
When you want to upgrade to Test Virtualization Control Panel 10.2.3 or later from 10.2.2 or an earlier version, or install Test Virtualization Control Panel 10.2.3 or later, and your existing workspace contains data about the configured stubs, scheduled tasks, or metrics databases, consider the following actions:
  • If you want to retain or reuse the existing Test Virtualization Control Panel workspace, you are indicated by the installer that the data will be migrated. The time to install or upgrade depends on the amount of data that exists.
  • If you do not want to use the existing workspace that contains data and select a different location to install the workspace, the following are the results:
    • An empty workspace is created.
    • Data in the existing workspace is not migrated.
    • Data in the existing workspace cannot be used with Test Virtualization Control Panel 10.2.3 or later versions.
To preserve the workspace (published stubs, user configuration, domains, and environments) of Test Virtualization Control Panel 10.2.2 or an earlier version, when you uninstall the previous version, ensure that you do not select the option to remove the workspace. When you install the later version up to 10.2.2, ensure that the workspace directory is set to the same location as your existing workspace.
Note: Starting from 9.2.1 onwards, the Test Virtualization Control Panel Environments page and the Agents page were replaced by dashboards. Those dashboards model stubs and scenarios differently and use new REST APIs, so existing test automation scripts that use the REST APIs before 9.2.1 operate differently.

After the upgrade or uninstallation, the contents of the workspace directory might change to work with the newer version of Test Virtualization Control Panel.

Configuring the X-Frame-Options HTTP response header

To help prevent possible clickjacking attacks, configure an X-Frame-Options HTTP header to be sent in the responses by performing the following steps:
  1. Stop Test Virtualization Control Panel, if running.
  2. Go to C:\Program Files\HCL\DevOpsTestControlPanel\usr\servers\defaultServer\apps\RTCP.war\WEB-INF\classes.
  3. Open the container.server.properties file and add a property named container.xFrameOptions. The value of this property is sent as the X-Frame-Options header value in the responses for web pages. For example container.xFrameOptions=SAMEORIGIN. If you do not add the property or specify no value for it, no header is sent.
  4. Save the changes.
  5. Restart Test Virtualization Control Panel.