This topic provides details specific to working with the local Virtualize Server.
Sections include:
For an overview of local vs. remote Virtualize servers, see Dedicated (Remote) Virtualize Servers vs. The Local Virtualize Server.
The local Virtualize server can be started and stopped from the Virtualize Server view or from the command line.
Starting and stopping the server is essentially starting and stopping:
To start the local Virtualize server:
You can stop the local Virtualize server (making any virtual assets on the local Virtualize server inaccessible) in any of the following ways:
To start the local Virtualize server from the command line:
"virtualizecli -startServer -data <workspace_dir> -localsettings <localsettings_file>" file
.When starting Virtualize in this way, the Start deactivated, release automatically when idle option (in Parasoft> Preferences> Parasoft> License) needs to be disabled. Otherwise, you won’t be able to add this server from another Virtualize installation’s UI.
You can use the following command line options with virtualizecli
:
-prefs "http://intranet.acme.com/Virtualize/workspace.properties"
-prefs "workspace.properties"\
For instructions on how to deploy virtual assets to the local Virtualize server, see Deploying Virtual Assets.
If you want to save local virtual asset settings before exiting Virtualize, right-click the Local machine node in the Virtualize Server view and choose Save Deployment Changes.
If your organization wants to monitor asset usage statistics for this server, you can configure the server to collect statistics, then view the collected statistics from either Virtualize or the CTP interface.
Server statistics collection can help you:
To view and modify server statistics collection:
parasoft.server.statistics.broker.port=<port>
To see a summary of server statistics in Virtualize, open the Virtualize server’s configuration panel, then review the statistics in the Monitoring tab.
"Unrecognized" refers to messages that were received by the Virtualize server, but did not match the listening paths on any virtual asset or HTTP proxy.
"Unmatched" refers to request messages that matched a virtual asset, but failed to match any responder correlations. The unmatched hits are grouped according to the request’s source IP/host and the first virtual asset that attempts to serve this request.
Additional details are available for viewing and export in CTP: