Setting up the Virtana AI Chatbot

Virtana AI adds a Copilot Chatbot to your monitoring environment so you can work with alerts, documentation, and insights through a conversational interface. The Copilot connects to an external large language model (LLM) provider that powers its responses. Before you enable the Copilot, you configure one supported provider, add the connection details to your Global View deployment, and turn on the related feature flags.

When the Copilot is enabled, you can do the following:

Interact with product documentation. Ask questions in natural language and get contextual answers drawn from Virtana's documentation.
Query alert-related information. Retrieve active alerts, alert history, and alert configurations without writing a query.
Generate alert policies and insights. Create alert policies and surface actionable insights based on data from your environment.

Supported model providers

This section describes the large language model (LLM) providers that Virtana AI supports. You must configure exactly one provider before you enable the Copilot, because the provider supplies the model that powers the chatbot, alert generation, and insights features.

The following table describes the three supported providers and when to use each one:

Provider	When to use it	Default inference endpoint
OpenAI	Choose OpenAI to connect directly to the OpenAI API and its hosted models (for example, GPT-4o and GPT-5).	`https://api.openai.com/v1`
Gemini	Choose Gemini to connect to Google's Gemini models.	`https://generativelanguage.googleapis.com/v1beta/openai/`
LiteLLM	Choose LiteLLM when you want a single gateway in front of multiple model backends, or when you run self-hosted or custom model deployments. LiteLLM provides a unified API across those backends.	Virtana-internal proxy URL. Set `VIRTANA_AI_INFERENCE_ENDPOINT` explicitly instead.

Note

When you set VIRTANA_AI_MODEL_PROVIDER to LITELLM, always set VIRTANA_AI_INFERENCE_ENDPOINT to your own proxy URL. The built-in default for LITELLM points to a Virtana-internal proxy that customer deployments can't reach, and Copilot fails to answer any question until you override it.

Configure the LiteLLM proxy for Virtana AI Copilot

A LiteLLM proxy gives you one place to manage large language model (LLM) credentials, route each Virtana AI workload to a model of your choice, log requests, and terminate TLS for backends that use private certificates. Virtana AI reaches the proxy over its OpenAI-compatible API, so the proxy is transparent to the Copilot features that use it.

LiteLLM model alias prerequisites

Create a model in your LiteLLM proxy for every Virtana AI model alias before you deploy Global View. When VIRTANA_AI_MODEL_PROVIDER is set to LITELLM, Virtana AI sends these aliases as literal model names, and a request for an alias your proxy doesn't define fails with a 4xx "model not found" error.

Map the aliases to OpenAI models as follows:

VIRTANA_MDL_MINI: 'gpt-4o-mini'
VIRTANA_MDL_NANO: 'gpt-4.1-nano'
VIRTANA_MDL_REASON: 'gpt-5.1'
VIRTANA_MDL_REASONING_MINI: 'gpt-5-mini'
VIRTANA_MDL_MINI_DEFAULT_CONFIG: 'gpt-4o-mini'
VIRTANA_MDL_MINI_CHATOPENAI: 'gpt-4o'
VIRTANA_MDL_MINI_ROUTEOPENAI: 'gpt-4o-mini'
VIRTANA_MDL_MINI_SWAGGER_ANALYSIS: 'gpt-4o-mini'
VIRTANA_MDL_MINI_GENERAL: 'gpt-5'
VIRTANA_MDL_MINI_GV_ALERT: 'gpt-4o-mini'
VIRTANA_MDL_MINI_GV_ALERT_TOOL_SELECTOR: 'gpt-4o-mini'
VIRTANA_MDL_REASON_GV_ALERT_RESPONSE_GENERATOR: 'gpt-4o'
VIRTANA_MDL_MINI_CHART_GENERATOR: 'gpt-4o-mini'
VIRTANA_MDL_MINI_METRICS_STATEMENT: 'gpt-4o-mini'
VIRTANA_MDL_REASON_METRICS: 'gpt-4o'
VIRTANA_MDL_REASON_INSIGHT_SVC: 'gpt-4o'
VIRTANA_MDL_REASON_TROUBLESHOOTING: 'gpt-4.1'
VIRTANA_MDL_NANO_IDENTIFIER: 'gpt-4.1-nano'

Map the aliases to Gemini models as follows:

VIRTANA_MDL_MINI: 'gemini-2.5-flash'
VIRTANA_MDL_NANO: 'gemini-2.5-flash'
VIRTANA_MDL_REASON: 'gemini-3.7-flash'
VIRTANA_MDL_REASONING_MINI: 'gemini-2.5-pro'
VIRTANA_MDL_MINI_DEFAULT_CONFIG: 'gemini-2.5-flash'
VIRTANA_MDL_MINI_CHATOPENAI: 'gemini-2.5-pro'
VIRTANA_MDL_MINI_ROUTEOPENAI: 'gemini-2.5-flash'
VIRTANA_MDL_MINI_SWAGGER_ANALYSIS: 'gemini-2.5-flash'
VIRTANA_MDL_MINI_GENERAL: 'gemini-3.7-flash'
VIRTANA_MDL_MINI_GV_ALERT: 'gemini-2.5-flash'
VIRTANA_MDL_MINI_GV_ALERT_TOOL_SELECTOR: 'gemini-2.5-flash'
VIRTANA_MDL_REASON_GV_ALERT_RESPONSE_GENERATOR: 'gemini-2.5-pro'
VIRTANA_MDL_MINI_CHART_GENERATOR: 'gemini-2.5-flash'
VIRTANA_MDL_MINI_METRICS_STATEMENT: 'gemini-2.5-flash'
VIRTANA_MDL_REASON_METRICS: 'gemini-2.5-pro'
VIRTANA_MDL_REASON_INSIGHT_SVC: 'gemini-2.5-pro'
VIRTANA_MDL_REASON_TROUBLESHOOTING: 'gemini-2.5-pro'
VIRTANA_MDL_NANO_IDENTIFIER: 'gemini-2.5-flash'

Each alias names the Copilot feature it serves and the model tier that feature needs. The tier tells you which upstream model to map an alias to when you don't want to use the defaults above: mini aliases need a fast, low-cost model, reasoning aliases need a stronger model, nano aliases need the fastest model available, and the embedding alias needs an embedding model.

Copilot refers to models by alias throughout the application, and resolves each alias at runtime based on VIRTANA_AI_MODEL_PROVIDER. Aliases are grouped by workload: MINI aliases handle fast, low-cost tasks, REASON aliases handle analysis and generation, NANO aliases handle identifier extraction, and VIRTANA_MDL_EMBEDDING handles document indexing and search.

The following table lists every alias, the model each provider resolves it to, and the model_name value your LiteLLM proxy must expose when VIRTANA_AI_MODEL_PROVIDER is LITELLM:

Model name	Description	OpenAI default	GEMINI default	LITELLM required `model_name`
`VIRTANA_MDL_MINI`	Fast, low-cost requests that no more specific alias covers.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI`
`VIRTANA_MDL_NANO`	Short extraction requests that need the fastest available model.	`gpt-4.1-nano`	`gemini-2.5-flash`	`VIRTANA_MDL_NANO`
`VIRTANA_MDL_REASON`	Primary reasoning model for analysis and generation.	`gpt-5.1`	`gemini-3.7-flash`	`VIRTANA_MDL_REASON`
`VIRTANA_MDL_REASONING_MINI`	Lightweight reasoning for shorter analysis tasks.	`gpt-5-mini`	`gemini-2.5-pro`	`VIRTANA_MDL_REASONING_MINI`
`VIRTANA_MDL_MINI_DEFAULT_CONFIG`	Calls that don't name a workload-specific model.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_DEFAULT_CONFIG`
`VIRTANA_MDL_MINI_CHATOPENAI`	Interactive chat responses in the Copilot conversation.	`gpt-4o`	`gemini-2.5-pro`	`VIRTANA_MDL_MINI_CHATOPENAI`
`VIRTANA_MDL_MINI_ROUTEOPENAI`	Routing a question to the Copilot capability that answers it.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_ROUTEOPENAI`
`VIRTANA_MDL_MINI_SWAGGER_ANALYSIS`	Analysis of API specifications.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_SWAGGER_ANALYSIS`
`VIRTANA_MDL_MINI_GENERAL`	General-purpose requests that aren't tied to one feature.	`gpt-5`	`gemini-3.7-flash`	`VIRTANA_MDL_MINI_GENERAL`
`VIRTANA_MDL_MINI_GV_ALERT`	Questions about Global View alerts.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_GV_ALERT`
`VIRTANA_MDL_MINI_GV_ALERT_TOOL_SELECTOR`	Selecting which tool answers a Global View alert question.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_GV_ALERT_TOOL_SELECTOR`
`VIRTANA_MDL_REASON_GV_ALERT_RESPONSE_GENERATOR`	Generating the answer to a Global View alert question.	`gpt-4o`	`gemini-2.5-pro`	`VIRTANA_MDL_REASON_GV_ALERT_RESPONSE_GENERATOR`
`VIRTANA_MDL_MINI_CHART_GENERATOR`	Generating charts from a request.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_CHART_GENERATOR`
`VIRTANA_MDL_MINI_METRICS_STATEMENT`	Building the metric query that answers a metrics question.	`gpt-4o-mini`	`gemini-2.5-flash`	`VIRTANA_MDL_MINI_METRICS_STATEMENT`
`VIRTANA_MDL_REASON_METRICS`	Analyzing metric data and explaining what it shows.	`gpt-4o`	`gemini-2.5-pro`	`VIRTANA_MDL_REASON_METRICS`
`VIRTANA_MDL_REASON_INSIGHT_SVC`	Insight generation.	`gpt-4o`	`gemini-2.5-pro`	`VIRTANA_MDL_REASON_INSIGHT_SVC`
`VIRTANA_MDL_REASON_TROUBLESHOOTING`	Troubleshooting analysis.	`gpt-4.1`	`gemini-2.5-pro`	`VIRTANA_MDL_REASON_TROUBLESHOOTING`
`VIRTANA_MDL_NANO_IDENTIFIER`	Extracting identifiers, such as resource names, from a request.	`gpt-4.1-nano`	`gemini-2.5-flash`	`VIRTANA_MDL_NANO_IDENTIFIER`

Note

The models listed above are the models Virtana tests and validates for chatbot functionality, alert policy generation, and insight generation. Using other models can produce inconsistent or unsupported behavior.

Choose how the proxy resolves model names

The value of VIRTANA_AI_MODEL_PROVIDER decides which model name Virtana AI sends, and your proxy has to recognize that name. Requests reach the proxy in both patterns below, because virtana_ai_inference_endpoint always sets the base URL.

Pick the pattern that matches your proxy configuration:

Aliases. Set VIRTANA_AI_MODEL_PROVIDER to LITELLM. Virtana AI sends VIRTANA_MDL_* aliases, and the proxy holds the complete mapping to upstream models, so you can change any mapping without redeploying Global View.
Provider model IDs. Set VIRTANA_AI_MODEL_PROVIDER to OPENAI or GEMINI. Virtana AI resolves each alias before sending the request, and the proxy must expose names such as gpt-4o-mini or gemini/gemini-2.5-flash.

Define the Virtana AI aliases in the proxy

Your litellm_config.yaml file must expose one model_name entry per Virtana AI alias when VIRTANA_AI_MODEL_PROVIDER is LITELLM. You can point all MINI and NANO aliases at one low-cost model and all REASON aliases at one stronger model, as long as every alias is defined.

The following example maps the aliases to OpenAI models:

model_list:
  # Fast, low-cost workloads
  - model_name: VIRTANA_MDL_MINI
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_DEFAULT_CONFIG
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_ROUTEOPENAI
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_SWAGGER_ANALYSIS
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_GENERAL
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_GV_ALERT
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_GV_ALERT_TOOL_SELECTOR
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_CHART_GENERATOR
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_MINI_METRICS_STATEMENT
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  # Interactive chat
  - model_name: VIRTANA_MDL_MINI_CHATOPENAI
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  # Reasoning workloads
  - model_name: VIRTANA_MDL_REASON
    litellm_params:
      model: openai/gpt-5
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_REASONING_MINI
    litellm_params:
      model: openai/gpt-5-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_REASON_INSIGHT_SVC
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_REASON_GV_ALERT_RESPONSE_GENERATOR
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_REASON_METRICS
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_REASON_TROUBLESHOOTING
    litellm_params:
      model: openai/gpt-4.1
      api_key: os.environ/OPENAI_API_KEY

  # Identifier extraction
  - model_name: VIRTANA_MDL_NANO
    litellm_params:
      model: openai/gpt-4.1-nano
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_NANO_IDENTIFIER
    litellm_params:
      model: openai/gpt-4.1-nano
      api_key: os.environ/OPENAI_API_KEY

  - model_name: VIRTANA_MDL_EMBEDDING
    litellm_params:
      model: openai/text-embedding-3-large
      api_key: os.environ/OPENAI_API_KEY

Every entry in the example uses the same four fields. The following table describes each field and the value to give it for Virtana AI:

Field	Description	Value to use for Virtana AI
`model_list`	The set of models the proxy exposes to its clients.	One entry for every alias that Virtana AI sends. An alias that is missing from this list fails with a 4xx "model not found" error.
`model_name`	The name a client asks for. LiteLLM matches the incoming request against this value.	The Virtana AI alias, spelled exactly as Virtana AI sends it, such as `VIRTANA_MDL_MINI`. Matching is exact.
`litellm_params.model`	The upstream provider and model that serve the request, in `provider/model` form.	The model you want that workload to use, such as `openai/gpt-4o-mini`. Several aliases can point to one upstream model.
`litellm_params.api_key`	The credential LiteLLM uses for the upstream provider, not the credential Virtana AI uses to reach LiteLLM.	Your provider key. The `os.environ/` prefix reads the value from the named environment variable in the proxy environment, which keeps the key out of the configuration file.

Start the proxy with this configuration and confirm that it serves an OpenAI-compatible /v1 API before you deploy Global View:

litellm --config litellm_config.yaml --port 4000

The command takes two options:

--config: Path to the litellm_config.yaml file that defines the model list.
--port: Port the proxy listens on. The port you choose must match the port in virtana_ai_inference_endpoint, which is 4000 in the examples in this topic.

Configure certificate trust for LiteLLM

A LiteLLM proxy is the supported way to reach an LLM backend that presents a self-signed or private certificate authority (CA) certificate. Certificate trust applies to two separate connections, so identify which one fails before you install a certificate:

Virtana AI to the proxy. When the proxy serves HTTPS with a certificate that the cluster doesn't trust, the virtana-ai pod fails to verify it. In-cluster deployments avoid this by using the proxy's internal service URL over HTTP.
The proxy to the LLM backend. When the backend presents a self-signed certificate, LiteLLM fails to verify it, and the proxy needs the issuing CA certificate.

Trust a private CA in the LiteLLM deployment

Mount your CA bundle into the LiteLLM container and point the standard SSL environment variables at it. LiteLLM uses Python HTTP clients that read the bundle path from these variables, so both must be set for all outbound requests to verify correctly.

env:
  - name: REQUESTS_CA_BUNDLE
    value: "/etc/ssl/certs/ca-certificates.crt"
  - name: SSL_CERT_FILE
    value: "/etc/ssl/certs/ca-certificates.crt"
volumeMounts:
  - name: enterprise-ca
    mountPath: /etc/ssl/certs/ca-certificates.crt
    subPath: ca-certificates.crt
    readOnly: true
volumes:
  - name: enterprise-ca
    configMap:
      name: enterprise-ca-bundle

Three values in this example must agree with each other: the mount path, the two SSL environment variables, and the ConfigMap key. The following table describes each field and the value to give it:

Field	Description	Default values
`REQUESTS_CA_BUNDLE`	The CA bundle that the Python `requests` library trusts.	The same path as `mountPath`.
`SSL_CERT_FILE`	The CA bundle that OpenSSL-based clients trust, including the HTTP client LiteLLM uses for provider calls.	The same path as `mountPath`. Set both variables, because different libraries read different ones.
`volumeMounts.name`	Which volume the container mounts.	The same name as `volumes.name`, which is `enterprise-ca` in this example.
`volumeMounts.mountPath`	Where the CA bundle appears inside the container.	Any path the container can read. Overwriting the system bundle at `/etc/ssl/certs/ca-certificates.crt` replaces the public CA list, so use a bundle that also contains the public CAs.
`volumeMounts.subPath`	Which key from the ConfigMap is mounted as a single file.	The key name you used when you created the ConfigMap, which is `ca-certificates.crt` in this example.
`volumeMounts.readOnly`	Whether the container can write to the mounted bundle.	`true`. The proxy only reads the bundle.
`volumes.configMap.name`	Which ConfigMap holds the CA bundle.	The ConfigMap you create in the next step, which is `enterprise-ca-bundle` in this example.

Create the ConfigMap from your CA bundle before you deploy the proxy:

kubectl create configmap enterprise-ca-bundle \
  --from-file=ca-certificates.crt=/path/to/ca-certificates.crt \
  -n <namespace>

The command takes three values:

enterprise-ca-bundle: Name of the ConfigMap. It must match volumes.configMap.name in the LiteLLM deployment.
from-file: The ConfigMap key and the local file it holds, in key=path form. The key must match subPath in the deployment, and the path is your CA bundle file in PEM format.
n: Namespace to create the ConfigMap in. It must be the namespace that runs the LiteLLM deployment, because a ConfigMap is only visible inside its own namespace.

Point Virtana AI at the proxy

Set virtana_ai_inference_endpoint to the proxy's in-cluster service URL so that traffic between Virtana AI and the proxy stays inside the cluster network and needs no additional certificate trust.

cp-configs:
  virtana_ai:
    virtana_ai_inference_endpoint: "http://litellm.<namespace>.svc.cluster.local:4000/v1"

Warning

Disabling TLS verification in LiteLLM sends provider API keys over connections that aren't validated, which exposes them to interception. Install the CA certificate instead of disabling verification.

Global View configuration

Virtana AI Copilot connects to a large language model (LLM) backend over an OpenAI-compatible API, and you can configure that connection in Global View with a small set of environment variables. You can connect directly to a public provider, or route every request through a LiteLLM proxy so that credentials, model routing, request logging, and certificate trust stay under your control. This section describes the supported providers, the three configuration patterns, and the rules that decide which model name Copilot sends.

Set the LiteLLM endpoint and key in global-view-values.yaml for a Helm-based deployment. The endpoint must be the OpenAI-compatible base URL of your proxy, which for most LiteLLM deployments includes the /v1 suffix.

virtana-ai:
  enabled: true
  env:
    VIRTANA_AI_MODEL_PROVIDER: "LITELLM"  
    VIRTANA_AI_EMBEDDING_PROVIDER: "OPENAI"
    VIRTANA_AI_EMBEDDING_ENDPOINT: "https://api.openai.com/v1"
cp-configs:
  virtana_ai:
    virtana_ai_api_key: "<litellm_proxy_key>"
    virtana_ai_inference_endpoint: "http://litellm.<namespace>.svc.cluster.local:4000/v1"

The following table describes each parameter in the configuration block, including the value to enter and when the value is required:

Parameter	Description and value
`virtana-ai.enabled`	Turns the Virtana AI Copilot Chatbot feature on or off. Set this to `true` to enable the Copilot.
`virtana-ai.env.VIRTANA_AI_MODEL_PROVIDER`	Names the LLM provider that powers Virtana AI. Enter one of the supported values: `OPENAI`, `GEMINI`, or `LITELLM`. The value must match the provider you configured.
`cp-configs.virtana_ai.virtana_ai_api_key`	Authenticates Virtana AI with your provider. Enter the API key for your chosen provider. This key is required for all three providers (OpenAI, Gemini, and LiteLLM). For LiteLLM, use the key that has access to every model name in the LiteLLM model configuration.
`cp-configs.virtana_ai.virtana_ai_inference_endpoint`	Sets the inference endpoint URL that Virtana AI calls. Leave this blank for OpenAI and Gemini, because they use their default public endpoints. If you run a self-hosted LiteLLM instance, enter the full endpoint URL, for example, `http://litellm.<namespace>.svc.cluster.local:4000/v1` or `https://litellm.example.com`.

For an OVA-based deployment, set the Virtana AI values in the /home/virtana/override-global-view-values.yaml file on the Global View appliance.

  cp-configs:
     virtana_ai:
       virtana_ai_api_key: ""
       virtana_ai_inference_endpoint: ""

   virtana-ai:
     enabled: false
     env:
      VIRTANA_AI_MODEL_PROVIDER: ""

The following table describes each parameter in the configuration block:

Parameter	Description	Default values
`cp-configs.virtana_ai.virtana_ai_api_key`	Authenticates Virtana AI with your model provider. Required for OpenAI, Gemini, and LiteLLM. For LiteLLM, enter the proxy key that has access to every model name in your LiteLLM model configuration.	"" (empty). The Copilot can't connect until you enter a key.
`cp-configs.virtana_ai.virtana_ai_inference_endpoint`	Sets the OpenAI-compatible base URL for inference requests. Leave blank for OpenAI and Gemini. For a self-hosted LiteLLM proxy, enter the proxy URL, for example, `http://<litellm_host>:4000/v1`.	"" (empty). When blank, Virtana AI uses the provider's default endpoint. The LiteLLM default is a Virtana-internal proxy that customer deployments can't reach, so always set this value for `LITELLM`.
`virtana-ai.enabled`	Turns the Copilot on or off. Set to `true` to enable it.	`false`
`virtana-ai.env.VIRTANA_AI_MODEL_PROVIDER`	Selects the LLM provider and which model names Virtana AI sends. Supported values: `OPENAI`, `GEMINI`, `LITELLM`.	"" (empty). When empty, Virtana AI uses `OPENAI`.

Both deployment types configure the same seven settings under different names.

Configuration variables

Copilot reads its connectivity settings from six environment variables. The three inference variables are required for every deployment; the three embedding variables are optional and inherit the inference values when you leave them unset.

The following table describes each variable:

Environment variable	Purpose	Default value
`VIRTANA_AI_MODEL_PROVIDER`	Selects the inference provider and the alias resolution behavior.	`OPENAI`
`VIRTANA_AI_API_KEY`	Authenticates inference requests. Must not be empty.	None. Legacy `OPENAI_APIKEY` and `OPENAI_API_KEY` are used as a fallback.
`VIRTANA_AI_INFERENCE_ENDPOINT`	Sets the OpenAI-compatible base URL for inference requests.	The default endpoint for the selected provider
`VIRTANA_AI_EMBEDDING_PROVIDER`	Selects the embedding provider, independently of the inference provider.	The value of `VIRTANA_AI_MODEL_PROVIDER`
`VIRTANA_AI_EMBEDDING_API_KEY`	Authenticates embedding requests.	The value of `VIRTANA_AI_API_KEY`
`VIRTANA_AI_EMBEDDING_ENDPOINT`	Sets the base URL for embedding requests.	The value of `VIRTANA_AI_INFERENCE_ENDPOINT`

Virtana recommends keeping embeddings on OpenAI regardless of which provider handles inference. The Copilot document search store is indexed with the OpenAI text-embedding-3-large model at 1024 dimensions, and any other embedding model produces vectors that the existing store can't match.

Warning

Changing VIRTANA_AI_EMBEDDING_PROVIDER or the embedding model on a system that already has an indexed document store makes document search return incorrect or empty results. You must re-index the document store with the new embedding model before Copilot answers documentation questions correctly again.

Scenario 1: Connect directly to OpenAI or Gemini

Connect directly to a public provider when your Global View deployment can reach the provider's API, and you don't need centralized credential management or request logging. Copilot resolves its model aliases to that provider's model IDs and calls the provider's default endpoint, so you only set the provider and the key.

The following example configures a direct OpenAI connection:

export VIRTANA_AI_MODEL_PROVIDER="OPENAI"
export VIRTANA_AI_API_KEY="<openai_api_key>"

To use Gemini instead, set VIRTANA_AI_MODEL_PROVIDER to GEMINI and supply a Gemini API key.

Scenario 2: Route through LiteLLM with model aliases

Set VIRTANA_AI_MODEL_PROVIDER to LITELLM when you want your proxy configuration, rather than Copilot, to decide which upstream model serves each workload. Copilot sends its internal aliases as literal model names, so your proxy holds the complete alias-to-model mapping, and you can change any mapping without touching Global View. Virtana recommends this pattern for proxy deployments.

The following example configures Copilot to send aliases to a LiteLLM proxy while keeping embeddings on OpenAI:

export VIRTANA_AI_MODEL_PROVIDER="LITELLM"
export VIRTANA_AI_API_KEY="<litellm_proxy_key>"
export VIRTANA_AI_INFERENCE_ENDPOINT="http://<litellm_host>:4000/v1"

export VIRTANA_AI_EMBEDDING_PROVIDER="OPENAI"
export VIRTANA_AI_EMBEDDING_API_KEY="<openai_api_key>"
export VIRTANA_AI_EMBEDDING_ENDPOINT="https://api.openai.com/v1"

Your litellm_config.yaml file must define a model_name entry for every alias listed in model aliases and their resolved model IDs. A request for an alias that the proxy doesn't define returns a 4xx "model not found" error, and the Copilot feature that uses that alias stops working.

Scenario 3: Route through LiteLLM with provider model IDs

Set VIRTANA_AI_MODEL_PROVIDER to OPENAI or GEMINI and point VIRTANA_AI_INFERENCE_ENDPOINT at your LiteLLM proxy when the proxy already exposes standard provider model names. Copilot resolves each alias to a provider model ID before it sends the request, so the proxy sees names such as gpt-4o-mini rather than VIRTANA_MDL_MINI.

If your LiteLLM proxy uses self-signed certificates or you need to skip TLS certificate validation, set VIRTANA_AI_SSL_VERIFY to "false". By default, this value is "true".

The following example sends OpenAI model IDs to a LiteLLM proxy:

export VIRTANA_AI_MODEL_PROVIDER="OPENAI"
export VIRTANA_AI_API_KEY="<litellm_proxy_key>"
export VIRTANA_AI_INFERENCE_ENDPOINT="http://<litellm_host>:4000/v1"
export VIRTANA_AI_SSL_VERIFY="false"

Set VIRTANA_AI_API_KEY to the LiteLLM proxy key in this pattern, not to your OpenAI or Gemini key. The proxy authenticates Copilot with its own key and uses the upstream provider key from its own configuration.

Note

VIRTANA_AI_MODEL_PROVIDER controls model name resolution only. It never overrides VIRTANA_AI_INFERENCE_ENDPOINT, so requests go to whichever endpoint you set, even when the provider value names a public provider.

VIRTANA_AI_SSL_VERIFY defaults to true. Set it to "false" only when bypassing certificate checks is necessary.

Enable GrowthBook feature flags

This section describes the feature flags that activate the Copilot and insights features for your end users. GrowthBook is the feature-flag service that controls which features appear in the product. After you deploy Global View with the configuration described in Global View configuration, set the two flags below in GrowthBook.

The following table lists each feature flag, the value to set, and the effect of that value:

Feature flag	Default value	Effect
`vp_disable_copilot`	`false`	Enables the Copilot Chatbot in the user interface. The flag controls the disable behavior, so a value of `false` turns the Copilot on.
`ipm_virtana_ai_insights`	`true`	Enables AI-powered insights generation in the IPM module.

In this section:

Setting up the Virtana AI Chatbot

Supported model providers

Note

Configure the LiteLLM proxy for Virtana AI Copilot

LiteLLM model alias prerequisites

Note

Choose how the proxy resolves model names

Define the Virtana AI aliases in the proxy

Configure certificate trust for LiteLLM

Trust a private CA in the LiteLLM deployment

Point Virtana AI at the proxy

Warning

Global View configuration

Configuration variables

Warning

Scenario 1: Connect directly to OpenAI or Gemini

Scenario 2: Route through LiteLLM with model aliases

Scenario 3: Route through LiteLLM with provider model IDs

Note

Enable GrowthBook feature flags

Search results